Re: Re[4]: Still cryptic OOP syntax

[skaller <skaller@...>]

On Mon, 2005-01-31 at 00:49, Gunnar Zötl wrote:
> >> [macros]
> >> As for "the whole thing": Dylan shows quite well that it can be done
> >> even for an algol-like syntax. I would not want to even come close to
> >> that kind of complexity for lua, though.
> 
> s> Contrarily, generalising Lua to allow such stuff should
> s> probably *simplify* the core, for example as above.
> 
> yep, that's probably right. But, talk about changing the core... I
> suspect that would make for a rather large change, in the ballpark of
> the new garbage collector for 5.1.

Nah! The GC is a major piece of complex code
which has to interact exactly right with a whole
lot of other stuff .. nasty!! Difficult!
Brave Lua developers! (LOL!)

The parser hooks at least don't look nearly
so bad. Lots of code may change, but it
can be changed one step at a time,
alternately refactoring but preserving
semantics, and then adding small localised changes.

EG: to make the new thing work, we need a Lua_state object.
So add one to the routine that needs it... don't use it,
just add it to the argument list.

Woops, a call fails. So add it to the call.
Recompile .. undefined symbol .. add to argument
of calling function .. keep going until you find
the place to to use an existing state object,
or create one. You're done.. and you can be 100%
sure nothing changed (because you're not using
the object!)

Well, now try to find the precedence table
and do a lookup. If anything fails -- which it
will initially -- fallback to the existing C table.

Hehe -- well now all you need to do is the BIG step.
Populate the table .. which can be done in Lua 
in a couple of lines and so should be reliable.

Hooking the 'statement parser' function will
be a bit harder, because it uses predefined 
C constants for keywords etc. Now we have
to handle new ones, so we need to fix that
up before actually trying to add a new
statement.

Perhaps again a table -- instead of using
the integer for the initial keyword,
make a string, then do a lookup,
call a lua CFuction to do the parsing,
then fiddle with the result to get back
to the form the C code requires.

This can be tested on the existing functions to
parse do, repeat, etc. This will be harder,
because the parsers have to do subparsing,
eg subparse an expression or other statements,
so there has to be a way to lookup the parsing
functions for each non-terminal.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net