01 Oct

Moon# 0.5.0 released!

I’ve released MoonSharp 0.5.0 (Moon#) the brand new Lua interpreter written entirely in C# for the best compatibility over .NET, Mono, Unity and Xamarin versions.

Many things have changed since the plans detailed in this blog.. for the best. Check it out.

Head to http://www.moonsharp.org

 

Filed under: Uncategorized

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
    : ...
    | exp binop exp | unop exp
    ;

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

unop
    : '-' | '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:

exp
    : ...
    | <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 
    | ...
    ;

operatorOr 
    : 'or';

operatorAnd 
    : 'and';

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

operatorStrcat
    : '..';

operatorAddSub
    : '+' | '-';

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

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

operatorPower
    : '^';

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.

MoonSharpArch

Filed under: MoonSharp, Uncategorized