|
|
|
@ -13,8 +13,8 @@ Quick reminders:
|
|
|
|
|
2. lauxlib.c has new functions raviL_loadbufferx() and raviL_dumpast()
|
|
|
|
|
3. ldo.c has new functions ravi_f_parser() and raviD_protectedparser()
|
|
|
|
|
4. Implementation of raviY_parser() is in ravi_ast.c
|
|
|
|
|
5. There is a new Lua api raviload() that calls ravi_load() - this can be used to start developing/testing the new parser.
|
|
|
|
|
6. There is a also a test driver test_ast.c.
|
|
|
|
|
|
|
|
|
|
Its been a while since I started this ... so cannot recollect now what the entry point was. I think the aim was to
|
|
|
|
|
allow the new parser to be called by using a new API function. The new parser is a pass through - i.e. it throws away everything
|
|
|
|
|
and eventually calls the existing parser so this way I can experiment with it without actually needing to generate code
|
|
|
|
|
just yet.
|
|
|
|
|
The new parser does nothing yet - it simply ends up calling the standard Lua parser. The idea is that we will have a passthrough
|
|
|
|
|
that is only used to test/build the new module without actually interfering with the existing flow.
|