frozen v. mutable

[Brendan Eich]

[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
> <Allen.Wirfs-Brock at microsoft.com> 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