Discuss
  • New Strawmen Ready for Discussion

New Strawmen Ready for Discussion

# Mark S. Miller (15 years ago)

Revised to address Allen's concerns with the previous proposal: < strawman:allen_wirfs-brock_s_comments_on_ephemeron_table_proposal>.

When previously presented on es-discuss and at the January committee meeting, the general sense was favorable, but it got stalled because of the objects Allen records in this note. With these concerns addressed, I suggest this strawman be considered again at the upcoming May committee meeting. Together with Proxies they enable membranes, finally making safe mashups practical code.google.com/p/es-lab/wiki/SafeMashups.

Brendan noticed bugzilla.mozilla.org/show_bug.cgi?id=445363#c20

that ES5/strict, and thus ES-Harmony, already makes proper tail calls (also known as tail call optimization) an unobservable optimization, and therefore allowed by the spec. However, merely allowing it does not say when programmers should be able to assume that the optimization is performed. This strawman takes steps towards specifying when programmers may make such assumptions. I do not suggest this be on the agenda for the May meeting, but I do not object if others wish to discuss it.

Since GC is unobservable, specifying it is tricky. This difficulty affects all GC-aware proposals: Ephemeron Tables, Proper Tail Calls, and the not-yet-ready Weak References < strawman:weak_references>. Here, I've

captured a start on a framework for specifying GC semantics. GC aware proposals should be specified in terms of this framework.

ES5 makes high integrity possible. One of the mission statements for ES-Harmony (at harmony:harmony#means)

is to provide syntactic conveniences for high integrity patterns. Const Functions are such a syntactic convenience. Although further syntactic conveniences may be desirable, I find that this one, together with the others already promoted from strawmen to proposals, is the minimal I need to make high integrity programming convenient. Examples are seen throughout the example use case in the ephemeron tables and weak reference strawmen. I suggest this also be considered at the upcoming May committee meeting.

# Gmail Dev (15 years ago)

On May 9, 2010, at 10:50 AM, "Mark S. Miller" <erights at google.com>

wrote: [...]

The case with const function expressions is a bit unclear.

What happens when:

var f = const g(){ function g(){}; };

Is f writable in this case but g isn't? Would executing f throw error
due to redeclaration of g?

# Mark S. Miller (15 years ago)

On Sun, May 9, 2010 at 2:52 PM, Gmail Dev <kangax.dev at gmail.com> wrote:

On May 9, 2010, at 10:50 AM, "Mark S. Miller" <erights at google.com> wrote: [...]

The case with const function expressions is a bit unclear.

What happens when:

var f = const g(){ function g(){}; };

Is f writable in this case but g isn't?

Yes. f is also visible in the containing scope. g is only visible within the function (or would be if it weren't shadowed).

Would executing f throw error due to redeclaration of g?

If I read the ES5 spec correctly, in the following code the declaration of g in the function body shadows the g declared by the function expression rather than redeclaring it. const should likewise shadow rather than error, as implied by the expansion shown on the strawman page.

var f = function g(){ function g(){}; };