[Metalua-list] Re: metalua source parsing

Fabien Fleutot fleutot at gmail.com
Sat Sep 13 17:25:57 GMT+2 2008

About the whole source recomposition thing: as you noted, it's quite complex
to establish a bijection between AST and sources.
Among other things that would be hard to notice: "function foo() end" vs
"foo = function() end", "function x:y() end" vs. "function x.y(self) end"
vs. "x.y = function(self) end", etc.

Globally, I fear that making the AST <-> source relation bijective would
turn the AST definition into a hairy mess: the reason why I built metalua on
lua is that the AST remains remarkably simple. Otherwise, a metapython would
have had a broader appeal :)

I think there's a more reasonnable way to perform code manipulation through
metalua without messing users' code formatting nor AST definition: perform
your manipulations on AST, of course, but then, splice the manipulated parts
into the original source file, rather than entirely regenerating it. Thanks
to the "char offset" location stored in lineinfos, it's easy to
programmatically retrieve the source snippet of an arbitrary piece of AST.

Maybe a clever "mlc.luastring_of_ast()" function would help: it would
generate a reasonable looking source code for ASTs without lineinfo, and
cut/paste source code extracts for the bits having lineinfos.

It might also make sense, in some cases, to check that the source
corresponds to its AST by:
- recomputing the AST of the source extract;
- check its structural equality with the primary AST.
This would catch the case of people tweaking a source-originated AST without
clearing its lineinfo fields.
A recursive lineinfo cleaner would also be handy.

About `Comment{ } nodes: they would add cases for code manipulation
programs, and I must say that find the idea terribly unlispy :) The reason
why I put comments into lineinfos is so that you can exploit metadata a la
doxygen or java attributes while retaining plain lua compatibility. But such
hack to hide metadata don't really make sense in full metalua: if you want
to handle more data, put in more syntax! Again, I can't think of a use case
where extracting bits of the original source file wouldn't do the trick.

There's one thing that might deserve a different implementation, though:
comments' lineinfo point to the boundaries of the comments' content,
excluding its delimiters. Maybe they should rather point to the whole
comment, delimiters included.

About the redundant presence of source file name in lineinfos: that's an
implementation artifact, which should move one level up indeed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.luaforge.net/pipermail/metalua-list/attachments/20080913/e27aef85/attachment.html

More information about the Metalua-list mailing list