[Cross-posting, interesting topics here.] On Jun 14, 2008, at 12:07 PM, Mark S. Miller wrote:
> On Sat, Jun 14, 2008 at 11:50 AM, Allen Wirfs-Brock > <[EMAIL PROTECTED]> wrote: >> While ugly, "const" meets my criteria. Aesthetics aside, const is shallow, analogous to a const reference type in C++, not a reference to a const type -- so you can set properties on an object denoted by a const reference, you just can't change the reference. This is disturbing. I've had a hard time thinking of a better term than const, though. BTW, earlier in this (es3.x-discuss only) thread you mentioned http:// www.erights.org/elang/kernel/auditors/, which I enjoyed and wanted to pass on to es4-discuss. The taxonomy you cited there (frozen, deep frozen, etc.) is helpful. It doesn't include anything so shallow as const, though, as E uses "def" to create such a constant binding. I wouldn't propose to add "def", it doesn't fit the full-word keyword style of JS. But it's arguably less overloaded than "const". (Another interesting point in that auditors page: the makeBrand example, which should be implementable in ES4 without problems -- but that is for another message.) >> >> What did we decide to do with the "const" declaration? Would this >> usage also be enough additional motivation to include it? > > On variables, we did decide to include "const", as it meets the > "parses on 3/4 browsers" criterion and it helps integrity. Oh, I didn't realize you had decided to include const in ES3.1 on this basis. IIRC, Opera treats const like var, which does at least let it parse. This could cause trouble -- we need to find out by testing (more below). > IIUC, our > meaning for it is exactly the meaning in ES4: the variable is > letrec-scoped to its containing block (as with ES4 "let") but the > variable is also unassignable. The variable declaration must provide > an initial value. An assignment to a const variable causes the program > to be statically rejected. The variable is initialized when its > initializing declaration is executed. (i.e., unlike functions, a const > variable's initialization is not hoisted to the beginning of its > block.) Any attempt to read the variable before it is initialized > fails. In strict mode this failure is a throw. In non-strict mode, the > failure is the reading of undefined. Did we agree to allow undefined be read before the declaration was evaluated? I thought at least Waldemar wanted const use before def always to be an error, in standard as well as strict mode. Note that all binding forms must be parented by a top-level program, function body, or block. No "if (condition) const FOO = 42;" where FOO is bound in the scope of the block or body enclosing the if. Apart from these nit-picks, this is a nice write-up, and it describes const in ES4 as proposed, but does anyone actually implement it yet in a proto-ES3.1 implementation? I think we should want interoperating implementations in some kind of alpha if not beta release, before standardization of ES3.1 as well as ES4. At this point we will get such implementations before standardizing ES4. The bug tracking ES4 const in SpiderMonkey is https://bugzilla.mozilla.org/show_bug.cgi?id=229756 I'll try to get this going for the 3.1 release of Firefox that's slated for late this year. > Given all the weird ways in which JavaScript likes to think of > variables and properties as similar, these uses of "const" are > compatible. Activation objects do exist in the ES1-3 specs, although they can't escape as references through which you could mutate a local variable behind the back of active function code. This matches some of the early implementations. It's another example of how I over-minimized in a hurry, 13 years and one month ago. :-/ /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
