[BrendanEich]

You seem to misunderstand "structs" -- see http://wiki.ecmascript.org/doku.php?id=harmony:binary_data, this is an extension of WebGL's typed arrays, which are already in all the new browsers (IE10 too).

As for implicit coercions, I enjoyed Gary Bernhardt's "Wat", referred to it, and at past talks even mocked along with. At Strange Loop, I went through each "Wat" in the "Wat Secrets Revealed" slide series (use down arrow when you see it greyed in).

Of course (!) I regret the implicit conversions that make == not an equivalence relation with disparate types on left and right (NaN is a different story: blame IEEE754). Who wouldn't? As I said at Strange Loop, some colleagues at Netscape were hot for lazy/loose number/string matching, and "I was an idiot! I gave them what they wanted."

There may be hope of fixing even ==, if we get macros done right. You would opt into macrology redefining == to be === or whatever you want. But this is in the future.

And that's the point: JS must grow compatibly, given its cursed/blessed position in the web. There is no other option that costs as little incrementally. True, we could paint into a corner. I don't see that happening, not with the vibrant and very smart JS developer community (communities, really) with whom we are working.

On a practical level, I once ran into someone who used to work at IDEO and became a JS hacker in the course of doing a startup. I asked him about == quirks and the like. He just shrugged and said "you learn what to avoid and move on." That is the voice of practical wisdom (until such time as macros help fix the quirks for good).

So my advice is cheer up!

[jarel]

> You would opt into macrology redefining == to be === or whatever you want.

Oh, please let the syntax for this be something like

  let == = ===;

:-P

[lowboy]

Let's not run an extra let statement if we don't have to!

    if (== != === || == !== ===)
      let == = ===;

[hermanhermitage]

Shouldn't that be var to get the right scope?

[saebekassebil]

May be off-topic but: Is it just me, or are macros just a new way to get confused while reading JavaScript? Introducing language-foreign syntactic constructs seems to me superfluous and confusing - This is the job of transcompiling languages like CoffeeScript.

[BrendanEich]

Reading the macros first helps. They must be defined at top of program or module, if I recall sweetjs.org's design correctly, for the staged hygienic expansion to work well.

Aside from that, you're right. But JS has higher order functions and objects with ad-hoc methods, so it can be used according to many paradigms, which can make it hard for a reader unfamiliar with the dominant paradigm in code at hand.

This is not a deal-killer for macros, although with sweet.js as the prototyping tool, your assertion about "This is the job" is satisfied. Sweet.js works with node to do AOT macro expansion at present. There's effort to integrate it in the browser too, but this will be easier with ES6 module loaders (not yet prototyped in SpiderMonkey or V8).

[saebekassebil]

Of course, as in every aspect of understanding, here for source code, it is important first to learn the context, here the macro definitions. My concern is that this will impose more than just a paradigm - it will impose new syntax which could effectively completely ruin the readability of JavaScript source.

The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable. Is the overall benefits of introducing macros to JavaScript really worth the costs of readability? And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?

[disnet]

> The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable.

True, but the same can be said of any API. Reading the definitions can help but for both complex macros and complex APIs built today out of just functions and objects you need to document your abstractions. Macros don't change this, they just give you another abstraction axis (syntactic) to work with.

As with most things it just depends on how you use it. Sure you can abuse macros to make tons of crazy, undocumented, hard to understand syntactic extensions that destroy readability. But you can already do that today. Used wisely macros can increase readability, used poorly they can decrease it.

> And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?

Not sure what you mean here. By definition macros are expanded at compile time (well, parse time really). The browser doesn't change this.

[saebekassebil]

I meant compile time of course, thank you for your clarifications. I'm eager to see how this turn out.

[dherman]

All abstractions can make your code unreadable; the key, as always, is to create good abstractions and document them clearly. Macros are syntactic abstractions. It's just as important to document them as it is for functions or objects. Of course, if you just have a little local macro that you're using for convenience, looking at the implementation may be sufficient. But when you write a macro that you want to share from a module, rather than requiring your clients to read the implementation, you document the syntax and the semantics, just like you would if you were writing a separate language.

But by having macros directly in JS, instead of having to use a whole language that compiles to JS, you can combine syntactic features from different sources. For example, right now there's no way to use one feature you like from CoffeeScript with another feature you like from TypeScript. You just can't combine them. But with macros, you could import two different syntaxes from two different libraries and use them in the same code.

On top of that, if we actually had macros in a future version of the standard, you wouldn't even have to precompile the macros offline, and you wouldn't need a preprocessing step at all. (For latency purposes, you might want to preprocess macros offline as an optimization. But for development, not having to do a preprocessing step is more convenient.)

Dave

[saebekassebil]

So this is all in the holy name of making JavaScript the assembly language of the web? Making it possible for every JavaScripter to write "his own" JavaScript syntax definitions meaning that I'll (as a contributor or just casual watcher) would have to read his whole collection of macros before I could begin to understand the code?

I don't think this can be compared to API's as they still follow the regular syntactic definitions - This will be like reading a completely new language every time I read a different repository. (Of course this is a worst-case scenario as I imagine that many macros will be used across several projects, but still.)

Is all hope gone for writing vanilla JS gone? And isn't macros kinda going in the opposite direction than the ES specs? There's no use for many of the ES6/7 features as they could just be mocked up in macros.