Tim Disney

shift doesn't have es2017 (`async`/`await`) support just yet so we're blocked on that. I hear it's being prioritized soon though.

That definitely clarifies things. Agreed that explicit phrasing looks like the way to go. Wish we could have avoided it but as your example shows it's not the worst thing...

Exactly. The plan is to cleanly integrate with npm. Both to install macros but also to import and use any existing npm library in case macros.

Yep we probably should include `begin-for-syntax`. Any ideas on good syntax for it? ``` js beginForSyntax { var id = function(x) { return x } } macro m { case...

Yep, I was long ago convinced the explicit/multiple instances approach is the right way to go for Sweet. Currently hacking on it as a matter of fact :) Thanks for...

@isiahmeadows we have basic [support implemented](http://sweetjs.org/doc/1.0/tutorial.html#_sweet_modules) for importing a macro along with importing `for syntax`. It's not full support by any means. It's only one phase level (no recursive imports)...

Indeed, `.next` should accept all the JS grammar productions but currently only knows about `AssignmentExpressions` (with alias `expr` since that's the one you usually want), `Expression`, and `Syntax`. The enforester...

I think the current behavior is "correct" as long as we're thinking of these APIs as being low level power tools. When you work at this level you must be...

So I just had a crazy idea. Syntax template are already syntactically special so what if we just don't escape them? Beginning (`#``) and ending (```) delimiters are always distinguished...

Oh! The trick is nested interpolations: ``` js let s = #` let ss = #`foo \${42}` `; ``` You'll need to count escapes for those I think.