global function declarations and predefined global properties

[Mark S. Miller]

On Thu, Jul 8, 2010 at 10:47 AM, Allen Wirfs-Brock <
Allen.Wirfs-Brock at microsoft.com> wrote:

>  > I'm very happy that Harmony itself will be a successor only to
> ES5/strict. That said, I do expect such lexical declarations to be de facto
> for non-strict code, so we should document as much agreement on their
> semantics as we can get. Perhaps at <
> http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors
> >?
>
>
>
> If it is going to be a de facto standard then it should be included in
> Harmony.  These days,  Microsoft’s primary interest in contributing to web
> standards development is to ensure interoperability of user written code
> among browsers.   We would much prefer that anything that is expected to be
> universally implemented in an interoperable manner is included in an
> official standard.   I don’t think we have any real disagreement here other
> than the possible perception that Harmony can only talk about strict mode
> functionality.
>

Yes, I think we're in agreement here on everything substantive. The issue --
which I wouldn't even characterize as a disgreement yet ;) -- is simply one
of spec naming and modularity. As long as we're agreed on semantics, I'm
easy on these more cosmetic issues. And I would like to see these issues
spec'ed.


>
>
> Allen
>
>
>
> *From:* Mark S. Miller [mailto:erights at google.com]
> *Sent:* Wednesday, July 07, 2010 10:56 PM
> *To:* Allen Wirfs-Brock
> *Cc:* es5-discuss at mozilla.org; es-discuss
>
> *Subject:* Re: global function declarations and predefined global
> properties
>
>
>
> [+es-discuss]
>
>
>
> On Wed, Jul 7, 2010 at 6:28 PM, Allen Wirfs-Brock <
> Allen.Wirfs-Brock at microsoft.com> wrote:
>
>  Yes, except that the ES5 spec. only defines what it defines…any
> non-standard extenders are on their own when trying to leverage ES5 spec.
> language so define their semantics. It may or may not fit some new use.
>
>
>
> Also, if you think that such non-strict lexical declaration are going to be
> a de facto standard language feature than you should probably be campaigning
> to add them to the Harmony standard.
>
>
>
> I'm very happy that Harmony itself will be a successor only to ES5/strict.
> That said, I do expect such lexical declarations to be de facto for
> non-strict code, so we should document as much agreement on their semantics
> as we can get. Perhaps at <
> http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors
> >?
>
>
>
>  If you wanted to have lexically scoped declarations within with blocks,
> why assume that they would add properties to the with object.  Why shouldn’t
> such declaration be defined in a declarative scope that is nested within the
> with object scope?
>
>  The conflict I was worried about is that both "with" and global scope use
> object environment records, effectively treating the top level as if within
> a
>
> "with (global) {...}" block. However, now that you raise it, we can
> retroactively rationalize "with" as creating an object environment record
> and nested within it a block-level declarative environment record <
> http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings#common_semantics>.
> By contrast, we explain global scope as just an object environment record.
> This justifies adding block level global declarations to the global object
> but not adding block level declarations to the with object.
>
>
>
> Great suggestion, thanks!
>
>
>
>
>
> *From:* Mark S. Miller [mailto:erights at google.com]
> *Sent:* Wednesday, July 07, 2010 5:58 PM
>
>
> *To:* Allen Wirfs-Brock
> *Cc:* es5-discuss at mozilla.org
> *Subject:* Re: global function declarations and predefined global
> properties
>
>
>
> AFAICT, the issue would also arise for "with" statements if the body of a
> "with" statement could contain a definition which is not hoisted around the
> "with". Although ES5 does not provide any such non-hoisted definitions,
> neither does it prohibit them. Three such non-hoisted definitions are
> expected in ES-next: "let", "const", and nested function definitions. Since
> several browsers are expected to support these for ES5 non-strict code[*],
> this issue will arise for "with" in these ES5 implementations.
>
>
>
>
>
> [*] <
> http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors
> >
>
>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100708/fa30343f/attachment-0001.html>