Sweet.js: Hygienic Macros for JavaScript

#1

Post by philf » Sun, Sep 23, 2012, 11:55 AM UTC

Sweet.js: Hygienic Macros for JavaScript
github.com

Re: Sweet.js: Hygienic Macros for JavaScript

#2

Post by [deleted] » Sun, Sep 23, 2012, 1:15 PM UTC

[deleted]

Re: Sweet.js: Hygienic Macros for JavaScript

#3

Post by saurik » Sun, Sep 23, 2012, 2:11 PM UTC

There seemed to be some confusion during the question and answer segment regarding the relative hygiene of macros in Clojure near the end of the motivation and design talk; while it was totally off-topic for the video (and it thereby made sense to take it offline), I personally wish I had been around afterwards to ask the guy who seemed so adamant that syntax-case was fundamentally better than the Clojure solution (which he claimed didn't do it correctly) why that was the case.

I'm totally willing to believe it, but based on my understanding (which sadly is somewhat limited for Scheme, but fairly in-depth for Clojure) it isn't intuitive to me: it would seem like the way you escape hygiene in Clojure (which by default achieves correct hygiene by attaching namespaces to symbols read for macros or inside of quasi-quote) is quite similar in semantics--but simpler in practice due to being exceedingly less verbose--than using syntax->datum and datum->syntax.

Re: Sweet.js: Hygienic Macros for JavaScript

#4

Post by saurik » Sun, Sep 23, 2012, 2:29 PM UTC

Despite spending a lot of time both in the design Wiki and in the talk discussing the importance of being able to determine whether a / indicates a regular expression literal or a division operator entirely within the lexer (as opposed to using the parser, which is how JavaScript is generally defined), the algorithm that this developer implemented does not actually work.

First off, an example where it works:

    a
    /5/
    7

If you run this through sjs you get:

    a / 5 / 7;

This is because, in JavaScript, statements continue across line boundaries until they are either explicitly terminated by a semicolon or a syntax error, in which case the parse is retried at that point as if a semicolon had been provided. In this case, that means we have a single statement that is a division of these three expressions: a, 5, and 7.

However, let's take a more difficult case:

    a = function() {}
    /5/
    7

This is also a single statement: you are entirely allowed to attempt to divide a function literal by a number, you will simply get the value NaN as output. If you take this file and run it through node, adding a "console.log(a)" to the end, that is in fact what you will get: NaN. However, when first run through sjs, you instead get "[Function]".

The reason is that sjs translated the code to:

    a = function () {
    };
    /5/;
    7;

This is incorrect, and demonstrates how difficult some of these underlying issues are when parsing languages that have intertwined lexer and parser state. :( Attempting some other test cases involving regular expressions (but not semicolon insertion) also failed: it seems a lot more work will need to be done on this before it will be able to process general input (and it is not 100% clear to me that the shortcut required is even possible: I haven't thought enough about it yet to say for certain, however).

(I work on the JavaScript parser for a compile-to-JS language used by people doing jailbroken-iOS development for live introspection of running processes, and thereby that was the first thing I was interested in: how well the parser worked. ;P I have intentions to add reader macros, and then replace all of the extra Objective-C syntax I added with them, but I haven't gotten around to it yet. FWIW: I actually found and fixed a bug in my parser while writing this comment. ;P)

Re: Sweet.js: Hygienic Macros for JavaScript

#5

Post by dherman » Sun, Sep 23, 2012, 5:34 PM UTC

saurik wrote: post #3

There seemed to be some confusion during the question and answer segment regarding the relative hygiene of macros in Clojure near the end of the motivation and design talk; while it was totally off-topic for the video (and it thereby made sense to take it offline), I personally wish I had been around afterwards to ask the guy who seemed so adamant that syntax-case was fundamentally better than the Clojure solution (w…

That was me. :) Caveat: I know more about hygienic macros than I do about Clojure, so I'm not in a position to critique Clojure specifically.

Hygiene is (roughly speaking) about getting scope right by default but has never been about forcing it on the programmer. Moreover, there are two components to it, only one of which is easy to achieve in an unhygienic system. It's easy to ensure your macro renames introduced /bindings/ by using gensym. But if your macro introduces /references/ to existing variables, it's very hard to protect against those references getting captured at the site where clients call your macro.

I believe in Clojure they get around this for some cases by letting you fully qualify a reference to a library binding, for example. But what if your macro wants to refer to a variable that's local to it? Such as an unexported library function, or simply a local variable. Again, I don't know if Clojure has an answer to this.

One concrete example: write a `define-inline` macro-defining-macro. At the call site, a user might write

    (define some-local-variable /* something */)
    (define-inline (foo x)
      (+ x some-local-variable))

In an unhygienic system, they should first of all fully-qualify the `+` to be safe (yuck!) whereas a hygienic system just gets that right by default. But more critically, how can they be sure that some client of `foo` won't write:

    (define some-local-variable "something else")
    (foo 42)

Not only will that break, it's not clear how to fix it. A hygienic system gets this right.

I do agree that the state of the art in hygienic macros is too complex. I just haven't seen another system that makes this kind of thing work. But I would like to experiment with Clojure's macros more to see if they have an answer.

Dave

Re: Sweet.js: Hygienic Macros for JavaScript

#6

Post by disnet » Sun, Sep 23, 2012, 5:35 PM UTC

saurik wrote: post #4

Despite spending a lot of time both in the design Wiki and in the talk discussing the importance of being able to determine whether a / indicates a regular expression literal or a division operator entirely within the lexer (as opposed to using the parser, which is how JavaScript is generally defined), the algorithm that this developer implemented does not actually work. First off, an example where it works: a /5/ 7…

Yeah there are certainly a few bugs remaining in the reader :)

It actually does the right thing if the function is named:

    a = function foo() {}
    /5/
    7

correctly translates to:

    a = function foo() {
    } / 42 / 7;

But clearly I missed the unnamed case. You mentioned finding a few other bugs? Would you mind submitting a bug report on github? I would love to fix those too!

Re: Sweet.js: Hygienic Macros for JavaScript

#7

Post by saurik » Sun, Sep 23, 2012, 5:46 PM UTC

disnet wrote: post #6

saurik wrote: post #4

Despite spending a lot of time both in the design Wiki and in the talk discussing the importance of being able to determine whether a / indicates a regular expression literal or a division operator entirely within the lexer (as opposed to using the parser, which is how JavaScript is generally defined), the algorithm that this developer implemented does not actually work. First off, an example where it works: a /5/ 7…

Yeah there are certainly a few bugs remaining in the reader :) It actually does the right thing if the function is named: a = function foo() {} /5/ 7 correctly translates to: a = function foo() { } / 42 / 7; But clearly I missed the unnamed case. You mentioned finding a few other bugs? Would you mind submitting a bug report on github? I would love to fix those too!

function a() { return /7/; }

Re: Sweet.js: Hygienic Macros for JavaScript

#8

Post by saurik » Sun, Sep 23, 2012, 5:50 PM UTC

dherman wrote: post #5

saurik wrote: post #3

There seemed to be some confusion during the question and answer segment regarding the relative hygiene of macros in Clojure near the end of the motivation and design talk; while it was totally off-topic for the video (and it thereby made sense to take it offline), I personally wish I had been around afterwards to ask the guy who seemed so adamant that syntax-case was fundamentally better than the Clojure solution (w…

That was me. :) Caveat: I know more about hygienic macros than I do about Clojure, so I'm not in a position to critique Clojure specifically. Hygiene is (roughly speaking) about getting scope right by default but has never been about forcing it on the programmer. Moreover, there are two components to it, only one of which is easy to achieve in an unhygienic system. It's easy to ensure your macro renames introduced /b…

Clojure does not have these issues: when the macro is called, the symbols are already attributed with the full namespace qualification, and usage of quasi-quote inside of the macro definition will also apply namespace qualification to variables local to the definition of the macro; you have to go out of your way to break this. You should spend more time looking into it before claiming to people that it doesn't work correctly; you could easily have just said "that's a good question, we'll look into that after the talk" rather than telling the person that Clojure wasn't as good.

Re: Sweet.js: Hygienic Macros for JavaScript

#9

Post by dherman » Sun, Sep 23, 2012, 6:05 PM UTC

saurik wrote: post #8

dherman wrote: post #5

Earlier quoted context omitted.

That was me. :) Caveat: I know more about hygienic macros than I do about Clojure, so I'm not in a position to critique Clojure specifically. Hygiene is (roughly speaking) about getting scope right by default but has never been about forcing it on the programmer. Moreover, there are two components to it, only one of which is easy to achieve in an unhygienic system. It's easy to ensure your macro renames introduced /b…

Clojure does not have these issues: when the macro is called, the symbols are already attributed with the full namespace qualification, and usage of quasi-quote inside of the macro definition will also apply namespace qualification to variables local to the definition of the macro; you have to go out of your way to break this. You should spend more time looking into it before claiming to people that it doesn't work c…

> Clojure does not have these issues: when the macro is called, the symbols are already attributed with the full namespace qualification, and usage of quasi-quote inside of the macro definition will also apply namespace qualification to variables local to the definition of the macro; you have to go out of your way to break this.

Again, not a Clojure expert, but a namespace is coarser-grained than individual local scopes, right? The problem I'm talking about is when you have a local variable inside a nested scope (e.g. inside a `let`). If this is not named by a namespace, then you would still get collisions.

Regardless, Clojure's approach seems to be much closer in spirit to a hygienic macro system: it attempts to get scoping correct by default, and allows you to intentionally capture.

> You should spend more time looking into it before claiming to people that it doesn't work correctly; you could easily have just said "that's a good question, we'll look into that after the talk" rather than telling the person that Clojure wasn't as good.

Fair enough as far as it goes. I did react snappily, but you didn't hear the offline conversation (this whole thing was a dialog at my office with a friend and colleague, incidentally) where I said "I'm not entirely sure, but I believe there are things you just can't express with systems like Clojure's." And we concluded, just as you reprimanded me to do, that we should look into it further when we have time.

Dave

Re: Sweet.js: Hygienic Macros for JavaScript

#10

Post by saurik » Sun, Sep 23, 2012, 6:29 PM UTC

dherman wrote: post #9

saurik wrote: post #8

Earlier quoted context omitted.

Clojure does not have these issues: when the macro is called, the symbols are already attributed with the full namespace qualification, and usage of quasi-quote inside of the macro definition will also apply namespace qualification to variables local to the definition of the macro; you have to go out of your way to break this. You should spend more time looking into it before claiming to people that it doesn't work c…

> Clojure does not have these issues: when the macro is called, the symbols are already attributed with the full namespace qualification, and usage of quasi-quote inside of the macro definition will also apply namespace qualification to variables local to the definition of the macro; you have to go out of your way to break this. Again, not a Clojure expert, but a namespace is coarser-grained than individual local sco…

Correct: I did not hear the private conversation. I only heard the talk that was made public along with this project that was posted here, and which was recommended as an information source, and pretty much serves as the web page and documentation for this project ;P.

> Again, not a Clojure expert, but a namespace is coarser-grained than individual local scopes, right? The problem I'm talking about is when you have a local variable inside a nested scope (e.g. inside a `let`). If this is not named by a namespace, then you would still get collisions.

Ok, so are you are concerned with the case where the person defining the macro uses a symbol from the namespace of the person using the macro but that symbol has been rebound by the user inside of a let surrounding the aforementioned usage of the macro?

If so, that requires a cyclic module dependency, which isn't allowed (as the namespace from which you are getting the symbol would need to be required, but it would have to require back to get access to the macro: it does eager name binding, so that can't happen).

If not, and you are just talking about the simpler and more obvious case of a let shadowing a binding inside of a larger scope used by a macro, that works fine. The following code prints "1100", despite the macro expanding to multiple uses of the same symbol "t".

    (def t 1000) 
    (defmacro run [x] 
        `(+ ~x t))
    (let [t 100] 
        (prn (run t)))

You might then wonder (as I have) whether this is implemented by simply renaming the variables bound by let to something random: that would be sufficient to implement this. However, if I go out of my way to unquote an unqualified symbol, I can capture: the following code prints "1200".

    (def t 1000)
    (defmacro run [x]
        `(+ ~x t ~'t))
    (let [t 100]
        (prn (run t)))