Re: Lua parser enhancement request

[Paige DePol <lual@...>]

Nagaev Boris <bnagaev@gmail.com> wrote:

> On Wed, Jul 29, 2015 at 11:23 PM, Dibyendu Majumdar
> <mobile@majumdar.org.uk> wrote:
>> Hi,
>> 
>> Ravi allows local declarations and function parameters to have
>> optional type annotations. This obviously makes any code using such
>> annotations incompatible with Lua.
>> 
>> It would be nice if Lua had a mode where it ignores any tokens between
>> a variables name and the comma or equal sign. That is:
>> 
>> local i: integer = 0
>> 
>> In the special mode Lua would ignore everything after 'i' upto the '='
>> sign.
>> Similarly:
>> 
>> function (a: integer, b: integer)
>> 
>> Here the text ': integer' would be ignored.
>> 
>> Ravi does not support annotating function return types - but I guess a
>> similar enhancement would allow optional return type annotation for
>> functions, but in this case making the parser determine what is to be
>> ignored is not easy as the syntax of the declaration would need to be
>> known.
>> 
>> A solution that does not dictate a specific type annotation syntax is
>> preferable as there is no standard way of defining types; and Ravi's
>> approach does not always match the approach taken by others.
>> 
>> This enhancement would allow Ravi programs to be run in Lua as Lua
>> programs.
>> 
>> Thanks and Regards
>> 
>> Dibyendu
> 
> I think, better solution would be to write Ravi-to-Lua converter,
> which can operate as Lua interpreter, converting code on the fly.

This is the exact approach I have taken with Lunia. In my opinion,
requesting such a change to a language simply to suit your own variant of
the language is not likely to succeed. The proposed change has no benefit to
regular Lua so why would it need to be added?

Instead of requiring Lua to change, for example, I added a preprocessor mode
which can take Lunia code and output Lua code for vanilla usage via a new
'luac' flag (outputs Lua code instead of bytecode).

Mostly this was to allow anyone who uses my Constants, Enumerations, Macro
and Inline patch (not yet released) to then generate vanilla Lua code while
still being able to use CEMI features... which themselves required
preprocessing anyways, so it was trivial at that point to generate source
and allow saving of it.

I also have an optional typing system, which via the preprocessor, can
simply omit the optional types and thus generate vanilla Lua code.
Interestingly enough, Dibyendu, we implemented our typing systems in a
nearly identical way. Though, I added my types as tokens for the lexer to
parse instead of doing string comparisons on TK_NAME tokens.

Sadly, I have not had as much time in the past year (wow, it's been a year
since my last patches were released!) to hack some Lua, though I will have
time again in the very near future... and have a lot of interesting things
planned, including a really nifty OSX program for visualising the internals
of a Lua program while it runs!

~Paige