Lua parser enhancement request

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lua parser enhancement request

Dibyendu Majumdar
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

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Coda Highland
On Wed, Jul 29, 2015 at 1:23 PM, Dibyendu Majumdar
<[hidden email]> 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
>

You could go the opposite direction, you know:

local i --[[:integer]] = 0

Ravi could parse the --[[: prelude and treat it as a type annotation,
while Lua will simply ignore it. This is what some typed Javascript
tools do.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Nagaev Boris
In reply to this post by Dibyendu Majumdar
On Wed, Jul 29, 2015 at 11:23 PM, Dibyendu Majumdar
<[hidden email]> 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.


--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Paige DePol
Nagaev Boris <[hidden email]> wrote:

> On Wed, Jul 29, 2015 at 11:23 PM, Dibyendu Majumdar
> <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Dibyendu Majumdar
On 29 July 2015 at 21:48, Paige DePol <[hidden email]> wrote:
> 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?
>

I was careful to not suggest a particular syntax that would suit Ravi
- instead just a generic ability to allow tokens that can be ignored.

I feel there are two benefits to the Lua community:

1. Firstly it allows type annotations to be legitimately added by
third-party products while still allowing Lua to run those programs.

2. Secondly it allows Lua programs to benefit from JIT compilation
technology in Ravi - although this may not be a benefit that you care
about.

Anyway - it is just a suggestion, I won't argue that the Lua community
needs this.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Dibyendu Majumdar
In reply to this post by Coda Highland
On 29 July 2015 at 21:26, Coda Highland <[hidden email]> wrote:
> You could go the opposite direction, you know:
>
> local i --[[:integer]] = 0
>
> Ravi could parse the --[[: prelude and treat it as a type annotation,
> while Lua will simply ignore it. This is what some typed Javascript
> tools do.
>

Sure, but I am keen to keep the syntax clean for Ravi.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Andrew Starks
In reply to this post by Coda Highland
On Wed, Jul 29, 2015 at 3:26 PM, Coda Highland <[hidden email]> wrote:
> You could go the opposite direction, you know:
>
> local i --[[:integer]] = 0
>
> Ravi could parse the --[[: prelude and treat it as a type annotation,
> while Lua will simply ignore it. This is what some typed Javascript
> tools do.
>
> /s/ Adam

This seems great to me. Ravi (or others) can parse the clean way and
the commented way.

A filter could convert code in both directions, if needed.

If inline comments were a common way to do something like this,
perhaps a more terse inline comment (perhaps with special
restrictions, such as no nesting or it ends when when an = sign is
present, as you're suggesting) would make some sense.

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Coda Highland
In reply to this post by Dibyendu Majumdar
On Wed, Jul 29, 2015 at 2:08 PM, Dibyendu Majumdar
<[hidden email]> wrote:

> On 29 July 2015 at 21:26, Coda Highland <[hidden email]> wrote:
>> You could go the opposite direction, you know:
>>
>> local i --[[:integer]] = 0
>>
>> Ravi could parse the --[[: prelude and treat it as a type annotation,
>> while Lua will simply ignore it. This is what some typed Javascript
>> tools do.
>>
>
> Sure, but I am keen to keep the syntax clean for Ravi.
>
> Regards
>

It's not that bad, and you could also use:

local i = 0 -- @integer

or

-- @integer
local i = 0

et cetera. Adding semantically-important annotations/directives in
comments has a lot of precedent:

Python proposal - https://www.python.org/dev/peps/pep-0484/#type-comments

Real-world Javascript -
https://developers.google.com/closure/compiler/docs/js-for-compiler?hl=en

Java analysis tool -
http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#annotations-in-comments

Turbo Pascal - don't have a link but it has significant comments for
preprocessor directives

Go language - https://golang.org/cmd/gc/#hdr-Compiler_Directives

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Andrew Starks
On Wed, Jul 29, 2015 at 4:17 PM, Coda Highland <[hidden email]> wrote:

> On Wed, Jul 29, 2015 at 2:08 PM, Dibyendu Majumdar
> <[hidden email]> wrote:
>> On 29 July 2015 at 21:26, Coda Highland <[hidden email]> wrote:
>>> You could go the opposite direction, you know:
>>>
>>> local i --[[:integer]] = 0
>>>
>>> Ravi could parse the --[[: prelude and treat it as a type annotation,
>>> while Lua will simply ignore it. This is what some typed Javascript
>>> tools do.
>>>
>>
>> Sure, but I am keen to keep the syntax clean for Ravi.
>>
>> Regards
>>
>
> It's not that bad, and you could also use:
>
> local i = 0 -- @integer
>
> or
>
> -- @integer
> local i = 0
>
> et cetera. Adding semantically-important annotations/directives in
> comments has a lot of precedent:
>
> Python proposal - https://www.python.org/dev/peps/pep-0484/#type-comments
>
> Real-world Javascript -
> https://developers.google.com/closure/compiler/docs/js-for-compiler?hl=en
>
> Java analysis tool -
> http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#annotations-in-comments
>
> Turbo Pascal - don't have a link but it has significant comments for
> preprocessor directives
>
> Go language - https://golang.org/cmd/gc/#hdr-Compiler_Directives
>
> /s/ Adam
>

ldoc/luadoc

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Petite Abeille
In reply to this post by Coda Highland

> On Jul 29, 2015, at 11:17 PM, Coda Highland <[hidden email]> wrote:
>
> Adding semantically-important annotations/directives in comments has a lot of precedent:

SQL hints :D

http://docs.oracle.com/cd/E11882_01/server.112/e41573/hintsref.htm#i17496


Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Coda Highland
On Wed, Jul 29, 2015 at 2:22 PM, Petite Abeille
<[hidden email]> wrote:
>
>> On Jul 29, 2015, at 11:17 PM, Coda Highland <[hidden email]> wrote:
>>
>> Adding semantically-important annotations/directives in comments has a lot of precedent:
>
> SQL hints :D
>
> http://docs.oracle.com/cd/E11882_01/server.112/e41573/hintsref.htm#i17496
>

I knew I was forgetting one that I'd used in the past! I think MSSQL
has similar, too. I know MySQL does.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Dibyendu Majumdar
In reply to this post by Dibyendu Majumdar
On 29 July 2015 at 22:00, Dibyendu Majumdar <[hidden email]> wrote:

> On 29 July 2015 at 21:48, Paige DePol <[hidden email]> wrote:
>> 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?
>>
>
> I was careful to not suggest a particular syntax that would suit Ravi
> - instead just a generic ability to allow tokens that can be ignored.
>

I think more serious objections are following:

1. The parser would be complicated if some nested structure was
allowed that could use the delimiter ',' -  e.g.:

    local x: {name: string, age: integer} = 0

    Of course Ravi doesn't allow this but others might.

2. The proposed approach doesn't allow for function return parameters
to be annotated.

3. There could be a requirement to declare types outside of local
statements or function parameters.


So I withdraw my suggestion as it is too limited in scope - and won't
really be generic enough.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Paul K-2
In reply to this post by Andrew Starks
>> local i --[[:integer]] = 0
>>
>> Ravi could parse the --[[: prelude and treat it as a type annotation,
>> while Lua will simply ignore it. This is what some typed Javascript
>> tools do.
>>
>> /s/ Adam
>
> This seems great to me. Ravi (or others) can parse the clean way and
> the commented way.
>
> A filter could convert code in both directions, if needed.
>
> If inline comments were a common way to do something like this,
> perhaps a more terse inline comment (perhaps with special
> restrictions, such as no nesting or it ends when when an = sign is
> present, as you're suggesting) would make some sense.
>

I took the same approach with integrating typedlua syntax into
ZeroBrane Studio analyzer (in a separate branch:
https://github.com/pkulchenko/ZeroBraneStudio/commits/static-analysis-typedlua).

One can write:

--[[interface Shape
  const new:(self, number, number) -> (self)
end]]
local Shape = require "shape"
--[[const]] function Shape:new(x --[[:number]], y --[[:number]])
print(self, x, y) return self end
local shape --[[:Shape]] = Shape:new(10, 10)
print(shape)

to get it properly parsed by (extended) typedlua analyzer. The
"standard" typedlua syntax is also supported, but this approach allows
to skip the compilation step and still get the type information into
consideration during static analysis.

Paul.

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Christian Thaeter
In reply to this post by Dibyendu Majumdar


On 2015-07-29 21:23, Dibyendu Majumdar 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)

Some silly idea, why not doing it the other way around and use existing
lua compatible syntax for ravi.

 local i__integer = 0
 function (a__integer, b__integer)

I know, we all hate hungarian notation, its overly verbose and failed
in various ways how it is proposed/used in C/C++.  

By using this in lua, the overly verbosity will remain. But it 'could'
shine in some other ways which are impossible in C/C++ where the actual
type definition and the variable name are not enforced to relate to
each other. Things will become even more interesting when custom types
(interface, prototypes, classes or whatever) come into play.

I am not thinking/proposing this as only way for type declarations, I
am well aware that many people will dislike it. But maybe it could be
an optional alternative or at least give some thoughts about a
different view of types in a dynamic language.

        Christian

>
> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Dirk Laurie-2
2015-08-01 1:05 GMT+02:00 Christian Thaeter <[hidden email]>:

>
>
> On 2015-07-29 21:23, Dibyendu Majumdar 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)
>
> Some silly idea, why not doing it the other way around and use existing
> lua compatible syntax for ravi.
>
>  local i__integer = 0
>  function (a__integer, b__integer)
>
> I know, we all hate hungarian notation, its overly verbose and failed
> in various ways how it is proposed/used in C/C++.

Oh, the verbosity can be cured, by borrowing an idea from
Fortran. (To go with origin-1 indexing, the arithmetic "for", etc.)

Give Ravi a function IMPLICIT (capitals, please! like C preprocessor
directives).

IMPLICIT ("integer", "[^I-N]")

If a name matches the pattern, values assigned to it must be
of the indicated type. Ravi would of course not treat IMPLICIT
as a function but as a compiler directive. It's a function to
allow Lua to do nothing.

To make Ravi programs compile under Lua, one can do this:

lua -e "IMPLICIT=load''" xxx.ravi

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Dibyendu Majumdar
On 1 August 2015 at 08:23, Dirk Laurie <[hidden email]> wrote:

> 2015-08-01 1:05 GMT+02:00 Christian Thaeter <[hidden email]>:
>> Some silly idea, why not doing it the other way around and use existing
>> lua compatible syntax for ravi.
>>
>>  local i__integer = 0
>>  function (a__integer, b__integer)
>>
>> I know, we all hate hungarian notation, its overly verbose and failed
>> in various ways how it is proposed/used in C/C++.
>
> Oh, the verbosity can be cured, by borrowing an idea from
> Fortran. (To go with origin-1 indexing, the arithmetic "for", etc.)
>
> Give Ravi a function IMPLICIT (capitals, please! like C preprocessor
> directives).
>
> IMPLICIT ("integer", "[^I-N]")
>
> If a name matches the pattern, values assigned to it must be
> of the indicated type. Ravi would of course not treat IMPLICIT
> as a function but as a compiler directive. It's a function to
> allow Lua to do nothing.
>
> To make Ravi programs compile under Lua, one can do this:
>

Hi,

Thank you for all the ideas. One thing to note about Ravi's optional
static typing is that unlike other implementations such as Typed Lua
or Typescript - once a value has a static type annotation, Ravi
strictly enforces this - as otherwise the JIT compiler could not
optimize the generated code. I need to use a solution that indicates
the guarantees provided by the language.

Using naming conventions alone is problematic as someone may have used
the naming convention already - and that would mean Ravi would
misinterpret existing Lua code. I am trying to ensure that in
interpreter mode at least, all valid Lua programs are valid Ravi
programs (this does break to a point as Ravi has smaller values for
some of the Lua limits due to the modified bytecode format).

The solution I was looking for was a way for Lua to allow third-party
type annotations in a generic way - which standard Lua would just
ignore. There have been suggestions to use comments - I think that
that approach is really not user friendly as the syntax becomes pretty
ugly. Also it complicates the implementation - as Ravi's type
processing is part of the language parser and run-time - it is not a
pre-processing phase.

The other suggestion to use a preprocessr to convert Ravi code to Lua
code - so that standard Lua can execute it - that's fine, and I may do
that - but it does require a user to explicitly invoke the
preprocessor.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Christian Thaeter


On 2015-08-01 12:22, Dibyendu Majumdar wrote:

> On 1 August 2015 at 08:23, Dirk Laurie <[hidden email]> wrote:
> > 2015-08-01 1:05 GMT+02:00 Christian Thaeter <[hidden email]>:
> >> Some silly idea, why not doing it the other way around and use
> >> existing lua compatible syntax for ravi.
> >>
> >>  local i__integer = 0
> >>  function (a__integer, b__integer)
> >>
> >> I know, we all hate hungarian notation, its overly verbose and
> >> failed in various ways how it is proposed/used in C/C++.
> >
> > Oh, the verbosity can be cured, by borrowing an idea from
> > Fortran. (To go with origin-1 indexing, the arithmetic "for", etc.)
> >
> > Give Ravi a function IMPLICIT (capitals, please! like C preprocessor
> > directives).
> >
> > IMPLICIT ("integer", "[^I-N]")
> >
> > If a name matches the pattern, values assigned to it must be
> > of the indicated type. Ravi would of course not treat IMPLICIT
> > as a function but as a compiler directive. It's a function to
> > allow Lua to do nothing.
> >
> > To make Ravi programs compile under Lua, one can do this:
> >
>
> Hi,
>
> Thank you for all the ideas. One thing to note about Ravi's optional
> static typing is that unlike other implementations such as Typed Lua
> or Typescript - once a value has a static type annotation, Ravi
> strictly enforces this - as otherwise the JIT compiler could not
> optimize the generated code. I need to use a solution that indicates
> the guarantees provided by the language.
>
> Using naming conventions alone is problematic as someone may have used
> the naming convention already - and that would mean Ravi would
> misinterpret existing Lua code. I am trying to ensure that in
> interpreter mode at least, all valid Lua programs are valid Ravi
> programs (this does break to a point as Ravi has smaller values for
> some of the Lua limits due to the modified bytecode format).

Legacy code will not contain type annotations anyway, you can just
provide a commandline option to switch explicit type annotations on/off,
with possibly different implementations how to declare types (for
backwards compatibility its prolly best to be off by default, then only
implicit inferred types are used)

....
> The other suggestion to use a preprocessr to convert Ravi code to Lua
> code - so that standard Lua can execute it - that's fine, and I may do
> that - but it does require a user to explicitly invoke the
> preprocessor.

Thats a great idea, especially when one could translate his
personal preferred naming conventions to types annotations eventually.

        Christian

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Tim Hill
In reply to this post by Dirk Laurie-2

On Aug 1, 2015, at 12:23 AM, Dirk Laurie <[hidden email]> wrote:


Oh, the verbosity can be cured, by borrowing an idea from
Fortran. (To go with origin-1 indexing, the arithmetic "for", etc.)

Give Ravi a function IMPLICIT (capitals, please! like C preprocessor
directives).

IMPLICIT ("integer", "[^I-N]")

If a name matches the pattern, values assigned to it must be
of the indicated type. Ravi would of course not treat IMPLICIT
as a function but as a compiler directive. It's a function to
allow Lua to do nothing.

To make Ravi programs compile under Lua, one can do this:

lua -e "IMPLICIT=load''" xxx.ravi

I actually liked the old Fortran model, and am sill ok with languages that use sigils for the same purpose (though Lua dropped them long ago). While making code look a bit more geeky they do have the huge advantage of clearly showing the type of the variable at its point of use as well as point of declaration (how many times have we had to hunt through #include files to find a hidden declaration?).

—Tim

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Dibyendu Majumdar
On 1 August 2015 at 19:21, Tim Hill <[hidden email]> wrote:

>
> On Aug 1, 2015, at 12:23 AM, Dirk Laurie <[hidden email]> wrote:
>
>
> Oh, the verbosity can be cured, by borrowing an idea from
> Fortran. (To go with origin-1 indexing, the arithmetic "for", etc.)
>
> Give Ravi a function IMPLICIT (capitals, please! like C preprocessor
> directives).
>
> IMPLICIT ("integer", "[^I-N]")
>
> If a name matches the pattern, values assigned to it must be
> of the indicated type. Ravi would of course not treat IMPLICIT
> as a function but as a compiler directive. It's a function to
> allow Lua to do nothing.
>
> To make Ravi programs compile under Lua, one can do this:
>
> lua -e "IMPLICIT=load''" xxx.ravi
>
>
> I actually liked the old Fortran model, and am sill ok with languages that
> use sigils for the same purpose (though Lua dropped them long ago). While
> making code look a bit more geeky they do have the huge advantage of clearly
> showing the type of the variable at its point of use as well as point of
> declaration (how many times have we had to hunt through #include files to
> find a hidden declaration?).
>

Not knowing Fortran I did not know about this feature. Sounds like a
cool feature, but not one that I think I can adopt.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Lua parser enhancement request

Roberto Ierusalimschy
In reply to this post by Dibyendu Majumdar
> Sure, but I am keen to keep the syntax clean for Ravi.

And we are keen to keep the syntax clean (and simple!) for Lua ;-)

-- Roberto

12