Re: Lua language extension for complex number and vector values

[Geoff Leyland <geoff_leyland@...>]

On 1/04/2011, at 8:51 AM, Francesco Abbate wrote:

> 2011/3/31 steve donovan <steve.j.donovan@gmail.com>:
>> Yes, although to handle full complex arithmetic you must parse such
>> expressions into some AST form in order to generate the real and
>> complex parts of the expression.  A bit messy, but the performance
>> benefits would be worth it.[1]
>> 
>> It doesn't feel like something that should or needs core changes -
>> more like a supercharged preprocessor with MetaLua-like capabilities,
>> but emitting Lua code for LuaJIT, etc.[2]
> 
> I agree with you. I'm converging toward a solution: write a new parser
> for a modified Lua language that will generate and AST to be given to
> LuaJIT. I'm more and more persuaded that this can be *the* good
> solution. I will be able to solve also other major problems like:
> - a simple syntax to access matrix elements like m[2,3]
> - how to have postpone arithmetic operations to optimize the whole
> expression (lazy evaluation)
> - elimination of cdata/userdata duality => only cdata can be used
> because the low level details will be hidden to the final user
> 
> This new language will be therefore like Lua but with native support
> for matrix and complex numbers and it will be based on LuaJIT2 to
> generate fast code. It sounds to me *very* promising. Unfortunately
> there is a lot of work to do to realize it. Basically I will need to
> - rewrite a LuaJIT2 parser so that we add an additional step that uses
> the AST between the parser and the code generator:
> 
>   parser <-> AST <-> code instrumentation
> 
> - write a parser for my language that generate an AST to be given to
> the AST => code generator.
> 
> This new language could be called ForLua :-)

I realise that you're talking about a language for writing numerical algorithms rather than a tool for defining systems of equations, but you really should take a look at rima: http://rima.incremental.co.nz/

FWIW I don't think you need to write a new parser for any of this if you're happy to work creatively within the Lua syntax. A parser might be nice one day, but I'd suggest prototype as far as you can within Lua and try to work around warts as best you can.  That's the approach I've taken with rima, and there are certainly a few awkward areas in rima syntax, but I keep finding ways to improve them, and I haven't had felt the need to write a parser yet.  At the moment parser would just be more code to maintain while I'm still trying to understand how rima should look.

Cheers,
Geoff