Re: Lua parser enhancement request

[Dibyendu Majumdar <mobile@...>]

On 1 August 2015 at 08:23, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2015-08-01 1:05 GMT+02:00 Christian Thaeter <ct@pipapo.org>:
>> 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