20 May

Moon# is online!

Moon# has its own website on GitHub : https://github.com/xanathar/moonsharp

Also, if you want to peek at the current backlog: https://www.pivotaltracker.com/s/projects/1082626


BTW, I’m moving all my open source efforts – however weak they might be – from various sources (mainly, here or google code) to GitHub, to have everything in one place.


[This post has been edited, as originally the project was hosted on CodePlex]

13 May

MoonSharp : operator precedence and associativity revised

Quite soon, I found the Lua grammar on the ANTLR github to skip operator precedence.

The old grammar is:

    : ...
    | exp binop exp | unop exp

    : '+' | '-' | '*' | '/' | '^' | '%' | '..'
    | '<' | '<=' | '>' | '>=' | '==' | '~='
    | 'and' | 'or'

    : '-' | 'not' | '#'

Obviously, there is no trace of operator precedence. A quick check to the Lua reference  tells us the precedence and also specifies operator associativity.  So I went with this:

    : ...
    | <assoc=right> exp operatorPower exp 
    | operatorUnary exp
    | exp operatorMulDivMod exp 
    | exp operatorAddSub exp 
    | <assoc=right> exp operatorStrcat exp 
    | exp operatorComparison exp 
    | exp operatorAnd exp 
    | exp operatorOr exp 
    | ...

    : 'or';

    : 'and';

    : '<' | '>' | '<=' | '>=' | '~=' | '==';

    : '..';

    : '+' | '-';

    : '*' | '/' | '%';

    : 'not' | '#' | '-';

    : '^';

Curiously, ANTLR syntax for <assoc=right> has changed somewhere between ANTRL 4.0 and 4.2, rendering the ANLTR4 reference wrong on that aspect. The manual says to write it like

rule : exp '^'<assoc=right> exp;

while now the <assoc=right> should be applied to the ‘:’ or ‘|’ :

rule :<assoc=right> exp '^' exp;

If using the first syntax (the manual one) the build emits a warning AC0157: rule ‘exp’ contains an ‘assoc’ terminal option in an unrecognized location

References to this peculiarity: TheAntlrGuy wiki and an helpful StackOverflow post.

Filed under: MoonSharp, Programming

09 May

Making MoonSharp – architecture and grammar draft

Ok a little update on the MoonSharp project.

I decided not to write a grammar from scratch. Rather, I’ll take the one from ANLTR github repository (https://github.com/antlr/grammars-v4/tree/master/lua) and modify it to suite my needs, eventually contributing back when done. I already noticed a couple of points to change which will be topic of future posts. I also planned originally to give precedence to a C# solution to a problem rather than a grammar solution in all cases where the cost is comparable (as I’m more expert in one than the other) but I’ve found (not unexpectedly) that it doesn’t happen often – most of the time it’s a lot easier to fix the grammar rather than work around it in C#

Architecturally I’m operating on a tree representation of the code directly derived from the AST. In practice what I’ll do is:

  • Use ANTLR generated lexer and parser to generate an AST of the script
  • Visit the AST and generate an almost parallel tree designed towards code execution (let’s call it Execution Tree)
  • Have the interpret model visit this second tree to produce a result

Obviously this is not the fastest of the approaches (although it’s pretty common among slow interpreters), so I plan on adding, at a later stage, a further step:

  • Use ANTLR generated lexer and parser to generate an AST of the script
  • Visit the AST and generate an almost parallel tree designed towards code execution (let’s call it Execution Tree)
  • Visit the Execution Tree and modify it to reap some optimization
  • Have the interpret model visit this optimized execution tree to produce a result

The good part would be that the interpreter would still be able to run on the unoptimized execution tree – for debugging, testing, optimization evaluation and so on.

A challenge here will be to find a way for the optimizer to rework the tree without violating encapsulation too much. To optimize the tree efficiently the optimizer has to know the intricacies of each tree node implementation and see how they could be reworked.


Filed under: MoonSharp, Uncategorized

05 May

Kick-starting MoonSharp

Disclaimer: name not definitive yet.

I’m working on an interpreter for a subset of LUA written in C#, with the help of ANTLR.

My target is at first learning ANTLR grammars and parsing with C# / Java.

Why C# and not Java ?

  • While I know Java pretty well, I’m a lot more fluent in C# (the difference between a language which is well known but seldomly used and one which I use everyday..)
  • LINQ has already been pretty handy to navigate the AST
  • Java has already its own interpreter, while C# only has native wrappers over native Lua
  • If this will ever have a use at all, it could be supporting scriping in Unity  – thus C#

Why Lua ?

  • Reason #4 of the previous point
  • It’s a language I’m comfortable with
  • The only other dynamic/interpreted language I’d see myself writing an interpreter for would be Javascript. I don’t know Ruby and Python well enough to write an interpreter of, and I don’t like other languages of that kind.

Why a subset and not the whole Lua ?

  • I don’t know how far I’ll go with this, thus committing to a subset makes sense
  • A lot of stuff in Lua is not needed to write great scripts (e.g. metatables)
  • A lot of stuff in Lua is specific to C/C++ integration (e.g. userdata)

Stay tuned!




Filed under: MoonSharp