> Andreas Rossberg <mailto:rossberg at google.com>
> September 6, 2013 9:50 AM
>
> But it doesn't. No matter which way you spec it, AFAICT, the
> difference is not observable from within the (spec'ed) language. We
> don't spec a debugger. Moreover, such details will already be
> dependent on implementation and optimisation anyway. So that does not
> strike me as a compelling argument. (If the spec really cared to guide
> debuggers, some notes could take care of that, but I don't think it
> makes sense to even try.)

Ok, noted. I would not be surprised if we do "go there", though.
>
> The price for not applying desugaring techniques is that we are
> pulling in a lot of unnecessary complexity and accidental
> inconsistency. I think it's quite a substantial cost, actually.
> Desugaring also is a great way of dog-fooding your own abstraction
> capabilities -- it can reveal language deficiencies quite
> relentlessly.

I actually agree, and the simplest desugaring by far, much better than 
closures, for

  (for (x of range(n)) for (y of range(m)) x*y)

is

  (function* () { for (let x of range(n)) for (let y of range(m)) yield 
x*y; })()

Desugaring FTW, indeed.
>
> [I guess your "of course" activated my ranting trigger here, given
> that small core languages plus well-defined desugarings were still
> regarded best practice last time I looked. ;)]

Yes, small kernel semantics, sugar (macros, if possible) for larger 
surface language spec, is still tops. Allen may have a thought. ECMA-262 
is not set up to facilitate this yet.

/be

Andreas Rossberg <mailto:rossberg at google.com> September 6, 2013 9:50 AM

> But it doesn't. No matter which way you spec it, AFAICT, the
> difference is not observable from within the (spec'ed) language. We
> don't spec a debugger. Moreover, such details will already be
> dependent on implementation and optimisation anyway. So that does not
> strike me as a compelling argument. (If the spec really cared to guide
> debuggers, some notes could take care of that, but I don't think it
> makes sense to even try.)

Ok, noted. I would not be surprised if we do "go there", though.

> The price for not applying desugaring techniques is that we are
> pulling in a lot of unnecessary complexity and accidental
> inconsistency. I think it's quite a substantial cost, actually.
> Desugaring also is a great way of dog-fooding your own abstraction
> capabilities -- it can reveal language deficiencies quite
> relentlessly.

I actually agree, and the simplest desugaring by far, much better than 
closures, for

```js
(for (x of range(n)) for (y of range(m)) x*y)
```

is

```js
(function* () { for (let x of range(n)) for (let y of range(m)) yield x*y; })()
```

Desugaring FTW, indeed.

> [I guess your "of course" activated my ranting trigger here, given
> that small core languages plus well-defined desugarings were still
> regarded best practice last time I looked. ;)]

Yes, small kernel semantics, sugar (macros, if possible) for larger 
surface language spec, is still tops. Allen may have a thought. ECMA-262 
is not set up to facilitate this yet.