Discuss
  • frozen v. mutable

frozen v. mutable

# Brendan Eich (17 years ago)

[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

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. :-/

# Lars Hansen (17 years ago)

-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich Sent: 17. juni 2008 17:26 To: Mark S. Miller; Waldemar Horwat Cc: es4-discuss at mozilla.org es4-discuss; es3.x-discuss at mozilla.org x-discuss Subject: Re: frozen v. mutable

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.

That is indeed the current ES4 design; reading before initialization always causes an error to be signalled. Ditto for 'let'. And of course const properties are write-once, there's no need to initialize it in the definition.

# Mark S. Miller (17 years ago)

On Tue, Jun 17, 2008 at 8:53 AM, Lars Hansen <lhansen at adobe.com> wrote:

From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich

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.

That is indeed the current ES4 design; reading before initialization always causes an error to be signalled. Ditto for 'let'. And of course const properties are write-once, there's no need to initialize it in the definition.

My mistake. I'm happy to have it always throw.