dherman

Think of it more like C (really more like a hybrid of C and JS) compiling to JS. It runs on the web, but it compiles to a very stylized kind of JS: it allocates a large typed array that represents a C-like heap and does its memory access on that typed array. This is the same basic approach that Emscripten uses for running C/C++ programs.

The purpose of this project is to experiment with a dialect of JS that integrates well with regular JS, so you can write performance-sensitive parts of your application in this dialect, and they can interoperate smoothly with the other parts of your normal JS code.

This is a project run by Michael Bebenita at Mozilla Research, along with our colleague Shu-Yu Guo.

I replied in a comment on my post, but Disqus is having issues today and anyway I want to say a bit more.

>> What should the expander do when it sees:

    quux (mumble, flarg) [1, 2, 3] { foo: 3 } grunch /wibble/i

> It expands it. The expander should not see a stream of characters, as you show in that example, it should see a tree.

This is the point: what tree? How many arguments does `quux` have? The answer isn't obvious, because `quux` isn't surrounded by any pair of delimiters. The net result: there isn't a clear way to write a JavaScript "lexer" that produces trees---i.e., a reader. JavaScript's syntax was not designed with this in mind, so there isn't a clear tree structure inherent in the syntax.

(And even if you solve that problem, there are aspects of the JS syntax that depend on knowing the parsing context, such as whether

    grunch /wibble/i

lexes as an identifier followed by a regexp literal or identifier-slash-identifier-slash-identifier. So the number of sub-nodes is not even clear until you expand enough to know what context that fragment appears in.)

These are all issues you'd have to sort out to figure out how to make JS amenable to macros. But what it amounts to is figuring out how to design a reader for JS. Or at least, if you wanted to design a Lisp-like macro system for JS, you would.

The point is, the fact that Lisp macros operate on trees (though syntactic trees, not "semantic" trees as you claim---that's a debate for another day) is directly enabled by being able to generate a tree rather than a stream of tokens from the reader. And that's only possible because the syntax was designed to support that. There's of course not just a single unique syntax that has this property, but Lispy languages have syntaxes that are designed to support a reader, and that's at the heart of what makes the Lisp approach to macros work.

I'm a friend of Matt's, and I enjoy his blog posts, but I'm afraid this post is full of bad advice and misinformation. He claims that `with` followed by an object literal is fully statically analyzable (it's not, because of prototypes), and he recommends using it without considering how badly it deoptimizes in all modern JS engines.

And spicyj is right that NaN is not equal to itself in most languages because that's how IEEE754 specifies it. In particular, this is true in Scheme, one of Matt's favorite languages. ;-P

(Also, depending on what he means by "true equality," his `equal` function fails to distinguish -0 and 0, which are distinct values in the language. However, I suspect those are best treated as the same value. It's extremely rare to want to treat -0 as if it exists at all.)

Haskell has curly braces and semicolons.

I use semicolons pretty heavily in Lisp. ;)

No ambiguity; if you put brackets around it you get a tuple (really, an array of fixed elements), and without brackets, the comma is part of the function signature. If you wanted to express your interpretation #1 you'd write:

    f :: ((Num) -> [Bool, Num]) -> Bool

Dave

It's a grammar hack, but IMO an intuitive one: if you have whitespace around the ::, it's a contract annotation; otherwise it's the prototype operator.

To quote Jeremy Ashkenas's JSConf talk on forking CoffeeScript: "when in doubt, cheat." ;-P

>> I think this document is either omitting the important details or it simply doesn't address the namespacing problem correctly. Remember when Prototype.js had a document.getElementsByClassName? Fun times when that broke.

Interfering with other modules' exports is not possible. But modifying the properties of arbitrary objects is just as possible as ever. Modules are all about fixing scope, not about locking down objects.

To put it differently, the document is not a module, it's an object. The module system has nothing to do with it.

>> How would one access a module declared in a <script type="text/es-harmony"> from a <script type="text/javascript">? It's a pretty realistic scenario (e.g. say you have a non es-harmony codebase and you want to add a es-harmony library)

This is accounted for in the design. The global object is not in the scope chain of Harmony code, but it is still available to Harmony code via a standard binding in the standard library, and the Harmony modules are made available to legacy JS as module instance objects in the global object. So communication is available in both directions.

First let me say that as a long time Schemer, and one who did his graduate work on the semantics of macros, I am quite positively disposed towards macros. In theory, I think it'd be great for JavaScript to develop a macro system.

That said, macros are much harder to design, and much less well understood, than modules. Worse, macros in the context of a dynamically loaded global scope (e.g., JavaScript's global object) are a complete mess. The Scheme community is actually quite divided over this issue. Some portions of the Scheme community favor a much more dynamic semantics for macros, more in the Lisp tradition; others favor building macros on top of a more compilation-friendly semantics -- often, not coincidentally, built on top of a static module system. As an example, I'd recommend looking into the Racket programming language (formerly known as PLT Scheme), which has a built-in module system fairly similar to the one we've designed for Harmony -- and which leverages this module system to support one of the most powerful macro systems in the history of programming languages.

Next, one of the central aims of the module system design is to correct some of the past mistakes in JavaScript's scoping semantics. These are things that can't just be desugared away by simple macros. They require actual changes to the way whole JS programs are compiled and executed.

Finally, I'll add that it's easy to write a few code snippets on your blog and pretend it's a design, but it's nowhere near what is required to see a design all the way through. It's not even enough for the introductory text of a proposal. But if you have serious proposals to make, I'd encourage you to join es-discuss and make positive, substantive contributions to the conversation. However, I should warn you that well-designed macro systems are still very much the stuff of research.