Re: [CFD] Local functions for Lua 4.1

[Reuben Thomas <rrt@...>]

>   2) Another Lua parser, written in Yacc or in Lua, and possibly much
>      slower than the default one, that people could change more easily.

luayacc and lualex in the style of Ocaml's camlyacc and camllex would be
wonderful (the good thing about Ocaml's lex and yacc is that they are
really just preprocessors for the compiler, so there is no sectioning of
code, they just let you use syntactically simple constructs for embedding
bits of lexers and parsers in your program. It's a very nice way to
program if you're parsing text a lot.)

> I think that (3) is much in the Lua spirit -- the default Lua parser
> would become a meta-mechanism for implementing similar languages with
> slightly different rules of scope... and it starts in a state that is
> simple and quite convenient for writing small programs...

This too is very much the way to go. Anything which lowers the bar to
experimenting with the language is a good thing; instead of having to
write patches in C, you could test the idea in Lua; for efficiency good
ideas might be better implemented in C, and very rarely you might want to
add a new feature to the core implementation.

For those who use Lua for scripting, however, a Lua written entirely in
Lua (apart from the VM) would be really useful. It's a pity that it would
necessarily perform rather badly, but for many applications it would be
much more flexible than the current implementation. If only there were
ways of messing with types to reduce the amount of dynamic checking that
you had to do, you could make Lua efficient too, but that is really
dreaming... (I am thinking of things like being able to assert the type of
a variable or argument, so that the program becomes at the same time
faster and unsafe).