No subject

> scoping ‘const’
> 
> scoping ‘const’ is not so much about how we write up the spec; there is a semantic definition problem - wanted const as applicable to vars and not on properties of objects with read barriers - but then what do we do about top level consts? - its base would be a special ‘object environment’ - const declaration treated as the creation of a property whose value was readonly - at the instantiation of the binding it would be set of ‘undefined’, ‘readonly’ and ‘configurable’- but readonly does not create a read barrier - strict mode needs to behave differently - read barrier needs to be unconditional - objection to semantics requiring a read barrier (from a performance perspective) - actually, in ES-H we will want ‘let’ and ‘const’ to behave consistently - looks like the semantics are not representable cleanly as the semantics of a property - two options to address the use-before-initialize problem (a) “dynamic dead zone”: runtime read barrier (b) “static dead zone”: set of stati
c rules that prevent the read -before-initialization, and thereby removing the need for a read barrier - dynamic dead zone is practical, but static dead zone would be better - not sure if we have the time to nail down the rules in time for ES3.1 - so we have the option of either going with the dynamic dead zone, or pulling const out of ES3.1.

If the object model we're pushing for 3.1 does not support top-level const then I believe the model is broken.  Trying to standardize such a model in ES3.1 seems premature, as it would risk blocking future evolution of the language.

    Waldemar