Traits library

[David Herman]

> Could macros - or some kind of AOP-ish compile time processing - help:
> @addtrait mytrait myobj;
> @import acme.mymod; // expands to const acme = {mymod: {myfunc: ...;

Macros wouldn't really solve the "I can't parse this" problem. You could package up syntax extensions as macros and provide them via modules, but you'd still then need to dynamically load the modules (or use server-side user-agent sniffing to produce web pages using different modules). And modules are a significant enough language feature that they deserve to be specified directly, not via translation.

> An ES-Harmony goal is to: "Provide syntactic conveniences ...defined by desugaring into kernel semantics."
> How could this be achieved? Macro source expansion? What is truly new 'kernel semantics' as opposed to syntax sugar? Interesting stuff.

This is a design/specification approach, not a technological thing. The idea is that some features can be described in the spec as sugar for something else that already exists. For example, IIRC, Java 5's introduction of for-in loops was described by desugaring.

Specification-by-elaboration is not entirely unproblematic. It has its place, but it's not an end unto itself. For one, the idea that a desugared construct doesn't change the semantics is hard to make precise without falling into the Turing tarpit.[1] Also, unless the desugaring is dead simple, it starts to turn into specification by implementation.

Dave

[1] For example, why isn't a full-fledged compiler "just desugaring?" There's some pretty intense theoretical research on the topic [2], but some decent rules of thumb: if your translation needs information about its context or deeply analyzes or rearranges the contents of its subterms, you've fallen into the tarpit.

[2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656