frozen v. mutable
brendan at mozilla.org
Tue Jun 17 08:25:50 PDT 2008
[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
I'll try to get this going for the 3.1 release of Firefox that's
slated for late this year.
> variables and properties as similar, these uses of "const" are
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. :-/
More information about the Es4-discuss