Re: Inline Functions

["Peter Hill" <corwin@...>]

Björn De Meyer:
> That way, the parser can handle lex errors and parse errors more
> uniformly. Although, it may slightly commplicate the design of the parser,
> as now, essentially, you now have an extra token, namely the "error"
> token.

Peter Hill:
> I'm thinking of trying to write the parser completely as an operator-based
> (bottom up) system, in which case there should be no extra overhead.

Hmm, so much for that idea. The non-homogenous syntax of Lua changes the
hierachy of some operators based on context which is going to be too
annoying. For example, the "," in an assignment is stronger that the "=":
    a,b,c = 1,2,3
while the "," in a table constructor is *weaker* than "=":
   {a=1, b=2, c=3}
Sigh.

Next plan... a nice simple fully top-down approach. Which leaves one
decision...

(a) Create a full parse-tree then use that to produce code. This gives a
better picture of the structure, and is ammenable to optimisation (if any
can apply)

(b) Perform an on-the-fly code production. This requires a lex-lookahead but
is how the Lua C-code current does it (I think) and doesn't require building
a temporary tree.

Which do you prefer, Björn?

*cheers*
Peter Hill.