I see, yes there is a potential eval tax. If I thought this was really a concern (and as you say, we already have the issue for catch and such) I'd be more inclined to fiddling with the scoping rule of eval rather than discarding lexically scoped consts. BTW, I think many of the use cases for such const are more in support of code generators then actual end user programming.
From: Brendan Eich [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2008 2:03 PM To: Allen Wirfs-Brock Cc: Mark S. Miller; [EMAIL PROTECTED]; [email protected]; Herman Venter Subject: Re: Update on ES3.1 block scoped function declarations On Jul 10, 2008, at 1:58 PM, Allen Wirfs-Brock wrote: Maybe, I'm missing something subtle, but 21 is clearly the right answer and is what I believe is specified by the version of section 10 that I sent out yesterday regardless of the scoping of block nested functions. Of course, that's just spec-ware... 21 is the right answer, I agree. But it requires reifying what could otherwise be lexical bindings the compiler tracks and then throws away, just so the compiler invoked by eval can see the bindings again. It's true that catch variables also need this kind of infrastructure, and named function expressions. So you could argue "in for a penny, ...". But block-scoped const in ES3.1, without let or function, is kind of half-a-pound, if you get my meaning. All the implementation cost, half the utility. /be From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich Sent: Thursday, July 10, 2008 1:45 PM To: Mark S. Miller Cc: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>; [email protected]<mailto:[email protected]>; Herman Venter Subject: Re: Update on ES3.1 block scoped function declarations On Jul 10, 2008, at 1:28 PM, Mark S. Miller wrote: On Thu, Jul 10, 2008 at 11:05 AM, Brendan Eich <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: So what would this program print in ES3.1? const C = 42; function f(x, y) { const C = 33; if (x) { const C = 21; return eval(y); } return C; } print(f(true, "C")); 21 What does it print in ES4-opt-in? Call it ES4, please. There's no point in playing games about opt-in, since we know we can't "break the web". ES3 added new syntax, so did ES2. No one bugged out about "opt-in". 21 is the right answer, although reflecting lexical blocks into something eval can see is a big pain (we did this in Firefox 2). It's a lot of work just for block-scoped const. Sorry if I missed the discussion, but was restricting const to top level considered? /be _______________________________________________ Es4-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
