Looks like a step in the right direction. I think the semantics of float-to-int conversion still needs more work to match.

Reversed opcode order and use snake_names everywhere. Also, made memory ops match AST semantics.

I tentatively used "/" to separate opcode index parameters, since using "[]" there does not fit the S-expression format all too well. Let me know what you think.

@lukewagner, @kg, do you think this part is good to land? The float truncation semantics should probably be addressed elsewhere (Dan has a WIP patch).

For brackets vs. slash: ideally, the opcode names in the SExpr format would exactly match those in AstSemantics.md. Since we're not actually trying to feed our SExpr language to a real LISP, is it ok if we bend the SExpr rules a bit and allow [/] in the identifier names? Or is there a basic parsing ambiguity?

+1 to exact match

-1 to some of the names currently in AstSemantics
-1 to brackets

And there went my karma for today

On Wed, Sep 2, 2015 at 6:54 PM, Luke Wagner notifications@github.com
wrote:

For brackets vs. slash: ideally, the opcode names in the SExpr format
would exactly match those in AstSemantics.md. Since we're not actually
trying to feed our SExpr language to a real LISP, is it ok if we bend the
SExpr rules a bit and allow [/] in the identifier names? Or is there a
basic parsing ambiguity?

—
Reply to this email directly or view it on GitHub
#33 (comment).

Using [] wouldn't currently cause a problem with the parser, but would still be rather odd. Maybe that's just me, though.

I'll be off the grid soon, so I hope it's okay if I land the current patch as is and leave the final bikeshedding for later. Should be trivial to tweak separately.

I'll also leave further changes to memory access ops to a future patch, since we are still discussing the best approach. Up to signedness, this patch remains close to what's currently in AstSemantics.

That makes sense; this patch already puts us a lot closer.