I would like an arrangement that combines opt-in and explicit
block-type notation.
A block is either scoping or non-scoping:
function Test (List)
{{
if (Debugging)
{
const DbName = "Test";
var Counter = 5;
}
for (var Num = 0; Num < List.length; ++Num)
{{
var Text = List [Num];
Result += Text [3];
}}
}}
Double braces {{ }} indicate a scoping block, single braces
{ } indicate a non-scoping block. A declaration binds the
name to the nearest surrounding scoping block {{ }}. A non-
scoping block { } can never bind a name. All the keywords
var, const, function etc. behave in exactly the same way
in this regard.
You opt in by using double braces at a point where a block is
possible. At the outermost level of the source text the old
rules apply. If you use { } the old rules remain in force.
If at any point you surround a block with {{ }}, then inside
this block double braces {{ }} are always scoping and single
braces { } are never scoping.
You can choose freely between scoping and non-scoping block
wherever this is supported by the standard. When a context
requires a certain type of block you must use the correct
markings, else a syntax error is thrown. There is no hidden
automatic correction, your notation must be correct. (But
only when you enable this.) This is so a programmer who
doesn't know the requirement is told. No hidden semantics!
So if the language requires that all function blocks must
be scoping, then when this is enabled you can only mark
function blocks with {{ }}. And if the language can't
deal with a certain construct written in a non-scoping
block, then you can only put this construct in blocks
that you mark {{ }}.
If peculiar rules are needed, they won't cause surprises if
they become opt-in together with the syntax change. But I'm
hoping that the above, together with clear compilation error
messages, can minimize peculiarities and make things clear
and simple.
Note that old browsers can compile source that uses this
syntax. However the meaning may be different. Hopefully
with suitable preparations and restrictions a linter or an
ECMAScript implementation can check the intended meaning
and analyze whether the program will have this intended
meaning when compiled in an old browser.
One unknown factor is that I don't know if the proposed
markings are sufficient for opt-in, or if something else
is required to avoid incompatible ambiguity.
The scoping rules of ECMAScript are becoming very complicated.
The behavior of the keyword "function" varies so much among
vendors that it can't be standardized,
https://mail.mozilla.org/pipermail/es3.x-discuss/2008-July/000280.html
"var" and "const" have now been specified to behave each in
its own way, and "let" requires many paragraphs of explanation.
I think the above can offer simplicity and clarity.
Ingvar
Brendan Eich wrote:
>
> On Jul 18, 2008, at 6:41 PM, Waldemar Horwat wrote:
>
>> We've been down this road before, and the arguments you present have
>> been hashed out over years. This approach doesn't work. Read the
>> archives of the ES4 group.
>
> Specifically, from the March 2008 meeting
> <http://wiki.ecmascript.org/doku.php?id=meetings:minutes_mar_27_2008%23technical_notes>:
>
> * ES3.1 and ES4 will both allow ‘function’ inside control flow
> statements [directly inside an explicit block, not as the lone unbraced
> consequent statement of an if, while, etc. /be], and it will be hoisted
> to the top of the block and initialized on block entry (to be compatible
> with how functions behave in ES3)
>
> * For ES4, ‘const’ is also scoped to the block, it is not hoisted, there
> is a read barrier, and it’s assign-once
>
> * For ES4, ‘let’ behaves like ‘const’ except that it’s not assign-once
>
> [end edited citation from the minutes. /be]
>
> This was Waldemar's counter-proposal to cut the gordian knot of too many
> declarative forms, some of which allow nonsense or wrongful capture.
> It's good, but it is also not compatible with the current browsers'
> intersection semantics for functions in blocks.
>
> This change requires opt-in versioning, which can be done based on
> page-specified MIME types, following RFC 4329 and HTML 5
> <http://www.whatwg.org/specs/web-apps/current-work/%23the-scripts> and
> real-world browser implementations. Note that script content typing
> depends on in-page type specification -- not on server MIME type to
> suffix mappings.
>
> For overconstrained problems created by different implementations
> operating within the rules of ES3 Chapter 16, there's no credible way
> forward other than opt-in versioning. That's what ES4 proposes. It is
> required for any block-scoped function, and even for const, since you
> can't get const past IE.
>
> When this last came up
> <https://mail.mozilla.org/pipermail/es4-discuss/2008-June/003048.html>,
> the suggestion as I understood it was for IE to be handled via scripted
> user-agent sniffing, presumably controlling document.write or DOM
> creation of script src= loading the const-ful or const-less code (or
> possibly eval, but eval does not scale). This is opt-in versioning by
> another name (the page author still has to opt and control script src,
> if not script type), and it's a bad idea to boot. User agent string
> contents are hard enough to parse, and overloaded for too many
> content-negotiation purposes already.
>
> My hope in this follow-up is twofold:
>
> * To highlight the need for opt-in versioning to clean up and evolve the
> language beyond certain points where it otherwise gets stuck.
>
> * To point out that script content type depends on in-page type
> selection mechanism, relieving the worry that was expressed recently
> during an ES3.1 conference call about server file-suffix-to-MIME-type
> mis-configuration.
>
> There are other possible ways to select version, including "use version
> N" pragma-strings. We haven't talked much about these, but they can be
> considered if their effects can be committed before the rest of the
> source following such a pragma is parsed. In light of all the possible
> ways before us, and the precedent in Mozilla for JS script types, the
> conclusion that opt-in versioning is infeasible or impractical needs to
> be demonstrated, not assumed.
>
> /be
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
--
Ingvar von Schoultz
------- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should all start with uppercase, because this will easily
and elegantly prevent a host of name-collision problems when things
like programming languages are upgraded with new labels.)
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
