On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote:
> On 3 January 2012 21:01, Brendan Eich <[email protected]> wrote:
>> On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
>>> On 3 January 2012 07:21, Brendan Eich <[email protected]> wrote:
>>>> The top level is hard. The only way to be sure is to use pure lexical
>>>> scope (in Dave's proposal, use module {...}).
>>>
>>> Ah, but wrapping into modules is incompatible with having multiple
>>> script parts.
>>
>> I don't know what you mean. "Incompatible" in the sense that you cannot
>> transform multiple scripts into multiple anonymous modules?
>
> Yes.
That's a feature, in the proposal. You want the old behavior? Use <script>
without |use module;| or |module {...}|. There's your backward compatibility
:-P.
>>> For multi-part scripts we need a way to switch the
>>> _proper_ top-level into extended mode. Or should I not be able to
>>> write (the relevant bits of) a multi-part script in extended mode at
>>> all?
>>
>> The proposal may have been unclear on this point: the top level would allow
>> as much new syntax and semantics as can be tolerated backwards-compatibly.
>> The hard cases are let, lexical scope in the free-variables-are-errors sense
>> Dave described (extant globals at start of module body are imported), and
>> any runtime shifts we want (completion reform, typeof null).
>
> I suspect there may be other subtle issues, e.g., what about `const'
Not supported by IE, ever -- no intersection semantics (unlike block-contained
functions).
> and local functions? [I see, Allen mentioned that already.]
Right. Oh, the pain! Still I don't want to fall back to versioning if these are
one of a few hard cases.
> In any case, even if we allow more features in classic mode
Don't think of modes and you'll be grooving with the new proposal better ;-).
> that
> still doesn't give you the ability to use _all_ Harmony features for
> multi-part scripts. I think we need a proper story for this.
Agreed, but this desire is best satisfied by markup, e.g. that <meta> tag idea
we've alluded to throughout this thread. Saying you want this doesn't undermine
the new-syntax-as-opt-in proposal.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
