Gabe Johnson

@disnet at the very least we should hide the editor controls that don't do anything.

This is still an issue. I have some ideas, but they involve changing our strategy for reading syntax templates. I'd also like to implement the ideas from https://github.com/sweet-js/sweet.js/pull/551#issuecomment-240721330 at the...

I would suggest defining `Number.prototype[Symbol.add]` in another file in the mean time.

> is this something that can be prototyped with sweet.js? Absolutely. Seems like you could just define a bunch of macros and dispatch to functions based on `MacroContext#name`. However, I...

@samuelgoto what you need is something along the lines of ```js import {unwrap, fromStringLiteral} from 'sweet.js/helpers' for syntax; syntax a = ctx => { const name = unwrap(ctx.name()).value; const dummy...

There's also nothing in the `a` macro specific to `a` so you could make this more generic with a helper imported from another file. ```js // tagHelper.js 'lang sweet.js'; export...

You'd either have to create a macro ```js syntax MyOwnTag = tagMacro; tags.MyOwnTag = ... ``` or create a new language once readtables are exposed as discussed in #687

The reader and enforester don't currently handle `async` and `await`. @disnet we'll have to update `sweet-spec`, and `tokens`, `enforester`, etc. and the version of `shift-codegen` I think.

I'd be in favor of the Babel option. Perhaps even better would be to do an AST transform instead. Then handoff to Babel. See #515 and https://github.com/shapesecurity/shift-spidermonkey-converter-js/issues/16

I can live w/ that. Maybe implement a `Symbol` method or two on `Term`. `match`/`destructure`. 👍 on the docs.