a little `private` quirk
Hi, let's assume a constructor than calls `this.reset(...)` method in the process of initialization of an instance; and that, this method sets up lot of object properties to set up initial state, including private ones using `private(this).foo = "bar";` kind of statements. It seems to me there is a little quirk, but maybe it is a feature: - when there is at least one `private x = ...;` statement in the constructor itself before the call to this.reset(...), everything works perfectly, even undeclared private fields are set up fine; - when there is not such a statement, this.reset(...) fails? There is no private variable record present. That is, my question is, does `private(this).foo = "bar";` create a private variable record if it is not present? Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
Hello,
sorry that I did not get it from the beginning.
You are right.
I am really concerned about use of boolean shortcuts in the context of
object initializer.
But François's examples scared me.
Especially the impossibility of `{ !window }.callFunc();` kind of
statements.
But in such case, early error should tell me I am in the wrong way and
people are accepting that this kind of construct need parentheses to
disambiguate (especially for the ({}).foo case).
So I would make the proposal alive again, but the thread got cluttered. :-/
Thanks again for showing me not to panic,
Herby
-Pôvodná správa-
From: Mike Samuel
Sent: Wednesday, January 04, 2012 6:29 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
2012/1/4 Herby Vojčík :
Curse that eval-uation of a code block! This prevents not only this, but a
lot of more possible enhancements/reforms!
I don't see the problem. You are proposing a change to the
ObjectInitialiser production. Francois's example just demonstrates
something we already know -- that there exist strings that will parse
as an ObjectInitialiser when you start in the Expression production
but parse as a Block when you start in the Program production.
eval('{ !window }') is and would remain a block, and eval('({ !window
})') with your proposal would be unambiguously an object initialiser,
and is a SyntaxError in ES5.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
In your suggestion, when an occurrence of destructuring (or any other new syntax) is seen, what unit of code is then opting in to strict? Would it be the nearest enclosing function, module, class, generator, or Program? I think I'm warming to the idea. I think having the opt-in unit be the destructuring pattern and everything recursively contained within it would be a bad idea. In this regard, destructuring is a different category of opt-in by new syntax than is module, class, and generator. On Wed, Jan 4, 2012 at 4:53 PM, Brendan Eich wrote: > On Jan 4, 2012, at 4:12 PM, "Mark S. Miller" wrote: > > > The problem I see is that the occurrence of some of these new features, > like a light use of destructuring, may not be notationally obvious to > readers. > > Maybe not, but for such users, strict mode may not be obviously a problem > either. This may well be the shortest path to migration and adoption, esp. > compared to version= lock-in. > > /be > > > > > > -- > > Cheers, > > --MarkM > -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape()
On Sun, Jun 13, 2010 at 7:50 AM, Jordan Osete wrote: > Hello everybody. > > How about standardizing something like RegExp.escape() ? > http://simonwillison.net/2006/Jan/20/escape/ > > It is trivial to implement, but it seems to me that this functionality > belongs to the language - the implementation obviously knows better > which characters must be escaped, and which ones don't need to. +1 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
How does |use es6| help for es7? It doesn't, especially if es7 has
runtime-incompatible changes (i.e., is not a superset).
Better to dispense with modes or ordered versions altogether, which is the key
idea of the proposal.
/be
Sent from my iPad
On Jan 4, 2012, at 4:45 PM, Axel Rauschmayer wrote:
> I think I would prefer a simpler per-file approach. In light of having to do
> something like this again for ECMAScript.next.next how about the following?
>
> First line:
> - "use strict"; // before ES5: ignore; ES5: ES5.strict
> - use es6; // ES6: ES6
> - module ? { is a synonym for use es6;
>
> With JS language versions being such a prominent issue on the web, I wouldn’t
> mind seeing at first glance what kind of code I am looking at.
>
> My idea might be completely off, but whatever the final solution, it should
> be dead-simple to explain.
>
> On Jan 5, 2012, at 0:56 , Mark S. Miller wrote:
>
>> (BTW I still think we want a real |use strict;| pragma, to choke old
>> implementations.)
>>
>> Yes. Crock suggested this in the old ES5 days and I think it is still a good
>> idea:
>>
>> "use strict"; // still runs on old browsers, but non-strictly
>>
>> use strict; // causes an early error on old browsers.
>>
>> Had we adopting it into ES5, it would have this meaning clearly. It may
>> still be a good idea, but consider the new complexity. Now the second form
>> also causes an early error on old ES5 browsers, where the script might
>> otherwise have been able to run strictly.
>>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:12 PM, "Mark S. Miller" wrote: > The problem I see is that the occurrence of some of these new features, like > a light use of destructuring, may not be notationally obvious to readers. Maybe not, but for such users, strict mode may not be obviously a problem either. This may well be the shortest path to migration and adoption, esp. compared to version= lock-in. /be > > -- > Cheers, > --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
I think I would prefer a simpler per-file approach. In light of having to do
something like this again for ECMAScript.next.next how about the following?
First line:
- "use strict"; // before ES5: ignore; ES5: ES5.strict
- use es6; // ES6: ES6
- module ? { is a synonym for use es6;
With JS language versions being such a prominent issue on the web, I wouldn’t
mind seeing at first glance what kind of code I am looking at.
My idea might be completely off, but whatever the final solution, it should be
dead-simple to explain.
On Jan 5, 2012, at 0:56 , Mark S. Miller wrote:
> (BTW I still think we want a real |use strict;| pragma, to choke old
> implementations.)
>
> Yes. Crock suggested this in the old ES5 days and I think it is still a good
> idea:
>
> "use strict"; // still runs on old browsers, but non-strictly
>
> use strict; // causes an early error on old browsers.
>
> Had we adopting it into ES5, it would have this meaning clearly. It may still
> be a good idea, but consider the new complexity. Now the second form also
> causes an early error on old ES5 browsers, where the script might otherwise
> have been able to run strictly.
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
We are now focused on "new syntax is opt-in" model. No new versions required
(allowed but not required). Even with new syntax we do not propose to make
existing syntax change meaning(much or at all) in ES.next.
/be
On Jan 4, 2012, at 3:23 PM, François REMY wrote:
> Is breaking current code so much of a problem? If, by default, javascript
> refers to "ES5" and if we introduce a "use version 6" pragma, breaking old
> code isn't a problem anymore. Scripting languages on UNIX are doing exactly
> this [http://en.wikipedia.org/wiki/Shebang_(Unix)]. The first line indicate
> the compiler/interpretor to use. That way you will never break the web, but
> you allow ECMAScript to move forward. We really need this.
>
> That doesn't mean we have to start over a new language but if, to make the
> language better, we have to make some changes that will have a minor impact
> on existing code (seriously, who is using code blocks at all?), this should
> not be a blocking issue. The comitee removed the with functionnality in ES5
> strict. That wasn't a problem. People can still use their old code and can
> opt-in for a new version with stricter rules.
>
> For people wanting to convert old code to ES6, there will be automated tools
> that can predict reliably if your code continues to work under ES6 and can
> notice you of problems. If those are rare engouh, most of our code will
> continue to run.
>
>
>
> -Message d'origine- From: Brendan Eich
> Sent: Thursday, January 05, 2012 12:03 AM
> To: es-discuss
> Subject: Re: Boolean shortcuts
>
> On Jan 4, 2012, at 2:56 PM, Brendan Eich wrote:
>
>> On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:
>>
>>> Hi,
>>>
>>> as I already posted in the parallel thread, there is that strawman called
>>> "do expression" by dherman that does just that.
>>>
>>> I feel like crying when I see how powerful data constructs could be if not
>>> hampered by "possible to parse as code block" ambiguity.
>>
>> Yes, I have felt like crying too -- I did some work (see
>> https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html)
>
> I should have also linked:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
>
> Of course,
>
> http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
>
> is much simpler.
>
> Neither addresses the empty-block/object issue by trying to evaluate {} as an
> object literal where today it's a block statement.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 1:07 PM, Brendan Eich wrote: [...] > See above. Function is implicitly strict. > I looked about and didn't see whatever I was supposed to notice. I would *love* for Function to be implicitly strict. But I have no idea how to do that without breaking the web. Function is a value on the heap shared by legacy non-strict scripts and newfangled Harmony strict scripts. So far we've been careful that the opt-in switches only per-code properties, not per-heap properties. How would this work. > > We need a normative spec, of course! But we do not need to support new > features in pre-strict-mode, indeed pre-ES6, combinations. New syntax is > the opt-in! > If all new syntax causes opt-in, that does effectively bar non-strict mode from being extended with non-strict versions of these primitives. That's a fine outcome, but I'm surprised to hear it. The problem I see is that the occurrence of some of these new features, like a light use of destructuring, may not be notationally obvious to readers. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 1:00 PM, Brendan Eich wrote: > > Anyway, predictions aside, I do not agree we should require "use strict" > if the syntax speaks for itself. > Is anyone saying that we should require this? I'm not. This sub-thread started with Dave's "module" as opt-in suggestion and you and I agreed earlier that "class" would also opt-in, so I'm not sure what you're arguing against. > > My argument is not against strict mode (the basis of Harmony!) but rather > against requiring "use strict"; directives to use new features that can be > expressed without incompatible meaning shifts (only with guaranteed early > errors in pre-Harmony implementations). We're already agreeing that there should be multiple ways to opt-in to strict mode, with "function*" joining this happy set. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hi Brendan, I agree with most of your message, so only commenting on the remainder. On Wed, Jan 4, 2012 at 12:52 PM, Brendan Eich wrote: [...] > > - After Dave's posting I foresaw people wanting implicit opt-in with > > other constructs, e.g. classes or uses of `import' -- and voila, we're > > already there. But even with that, you still have to rely on explicit > > opt-in (via "use strict"?) for enabling some features elsewhere. > > Which features? > Lexical scoping (top level aside of course). Encapsulated functions. Sane arguments. Poisoning of .caller, .callee, .arguments. Ability to write code that continues to run on old browsers and to run sanely on old ES5 browsers. Throw errors on failed assignment rather than silently continuing as if everything is fine. Throw exception on a failed delete. Throw on assigning to an undefined variable rather than having misspelling silently create a new global. Preventing an eval from corrupting its caller's scope. Need I go on? Compared to ES5 strict, ES5 non-strict is insane. Regarding adoption of strict, another audience we should keep in mind is people newly learning JavaScript. Would you rather teach them to say "use strict"; or teach them to program in a language without sane scope rules or encapsulated functions, and with silent errors? No -- "use strict"; the string literal expression-statement is meaningless > pre-ES5, ES5-strict in ES5, and redundant in Harmony code. I don't see how it can be redundant in harmony code. Say I write a script, intending it to be harmony, but which doesn't begin with "class", "module", "function*", or whatever else we decide is a new opt-in. But I want the code above the first, say "module", to still obey harmony rules rather than non-strict rules. I would still need to say something else at the top of the script to ensure this. > > (BTW I still think we want a real |use strict;| pragma, to choke old > implementations.) Yes. Crock suggested this in the old ES5 days and I think it is still a good idea: "use strict"; // still runs on old browsers, but non-strictly use strict; // causes an early error on old browsers. Had we adopting it into ES5, it would have this meaning clearly. It may still be a good idea, but consider the new complexity. Now the second form also causes an early error on old ES5 browsers, where the script might otherwise have been able to run strictly. > > Now what do you say? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Make method semantic identical in classes and literals
Ok, thanks. If my opinion counts, then I am definitely at the side of "methods should be writable and configurable unless declared const". ;-) Herby -Pôvodná správa- From: Allen Wirfs-Brock Sent: Thursday, January 05, 2012 12:13 AM To: Herby Vojčík Cc: es-discuss@mozilla.org Subject: Re: Make method semantic identical in classes and literals As it stands right now there are still other more significant outstanding issues relating to both proposals that need to be addressed. As those get resolved we will make then as consistent with each other as makes sense. I think there is wide agreement that "methods" should be should be non-enumerable. There may be less agreement on whether they should be non-writable or non-configurable. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
Hi,
thanks for the link. I will look at it. I am just working on something
similar, just because it appeared inside my mind and it is really nice (if
it was possible). So I probably will finish it and put it online, even if it
will be put away (though I'd like not to).
I'm curious about in what scenarios {} as object literal brings is a
breaking change.
I devised a "freestanding {...} is always an object literal" rule with "if
you want free code block, introduce it in appropriate context" (like a
do-expression, for example, even dumb do while (0) is good as a workaround)
counsel. I see it breaks old code, but I am looking at it as a feature for
the new version, so breaking old code is not a problem and I do not see
(yet) any problems when used in context of ES.next only. Is there something
beyond free code blocks?
Herby
-Pôvodná správa-
From: Brendan Eich
Sent: Wednesday, January 04, 2012 11:56 PM
To: Herby Vojčík
Cc: François REMY ; mikesam...@gmail.com ; es-discuss
Subject: Re: Boolean shortcuts
On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:
Hi,
as I already posted in the parallel thread, there is that strawman called
"do expression" by dherman that does just that.
I feel like crying when I see how powerful data constructs could be if not
hampered by "possible to parse as code block" ambiguity.
Yes, I have felt like crying too -- I did some work (see
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html) on
unifying blocks and object literals, inspired by others on this list, but it
didn't pan out. It's increasingly future-hostile as we try to extend object
literals.
Trying to invert precedence so "{}" as a program source makes an empty
object instead of an empty block, IOW favoring expressions over statements,
is a breaking change. Not only for eval, but for other variants such as
javascript: URLs.
So, I've put unifying blocks and object literals on the back burner. A more
nuanced approach that doesn't break compatibility so much would be welcome,
but I don't see it.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 12:16 PM, Brendan Eich wrote: > > And for classes. > "class" is unconditionally reserved, so there's no issue. > And for generators? > I like the idea of generators as yet another strict opt-in, even though recognizing "function*" is technically an example of the "previously-illegal token sequence" approach. It does feel like an example of it readability wise. The eye rapidly learns to see "function*" as a keyword. The extra grammar complexity to recognize it is minimal. > If yes for generators, then why not for comprehensions, rest/spread, > destructuring (separate from the 'let' issue), for/of, and other new forms? > I hadn't thought about comprehensions. As for rest/spread and destructuring, sure, if there's no complexity. However, Allen just pointed out that there would be complexity for allowing non-strict destructuring, so let's not. If we run across problems with the others, then probably not for those either. We've got enough important things to do that we shouldn't waste any time enhancing non-strict mode when doing so is non-trivial. > > /be > > -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 9:35 AM, Allen Wirfs-Brock wrote: > On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > [...] > BTW, The simplest way to work around these issues, that I've found, would > be to say that any function that uses any new formal parameter syntax is > implicitly a strict mode function. Good arguments -- both you and Andreas. I withdraw the suggestion that these be normative optional -- it indeed accomplished nothing useful. Instead, we simply do not forbid them in non-strict mode, which as you observe has always been the status quo. I accept that destructuring is problematic for reasons I've overlooked. No doubt others are too. For each one, the first solutions we should reach for are 1) leave them out of strict mode, or 2) (as you suggest) make its presence an implicit opt-in to strict mode (which amusingly does effectively forbid it from appearing in non-strict code). For destructuring, I think it is less suggestive notationally that it represents a boundary at which rules change, so I would rather simply omit it from non-strict mode. But either way would avoid these specification complexities, which I agree we should avoid. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
Is breaking current code so much of a problem? If, by default, javascript
refers to "ES5" and if we introduce a "use version 6" pragma, breaking old
code isn't a problem anymore. Scripting languages on UNIX are doing exactly
this [http://en.wikipedia.org/wiki/Shebang_(Unix)]. The first line indicate
the compiler/interpretor to use. That way you will never break the web, but
you allow ECMAScript to move forward. We really need this.
That doesn't mean we have to start over a new language but if, to make the
language better, we have to make some changes that will have a minor impact
on existing code (seriously, who is using code blocks at all?), this should
not be a blocking issue. The comitee removed the with functionnality in ES5
strict. That wasn't a problem. People can still use their old code and can
opt-in for a new version with stricter rules.
For people wanting to convert old code to ES6, there will be automated tools
that can predict reliably if your code continues to work under ES6 and can
notice you of problems. If those are rare engouh, most of our code will
continue to run.
-Message d'origine-
From: Brendan Eich
Sent: Thursday, January 05, 2012 12:03 AM
To: es-discuss
Subject: Re: Boolean shortcuts
On Jan 4, 2012, at 2:56 PM, Brendan Eich wrote:
On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:
Hi,
as I already posted in the parallel thread, there is that strawman called
"do expression" by dherman that does just that.
I feel like crying when I see how powerful data constructs could be if
not hampered by "possible to parse as code block" ambiguity.
Yes, I have felt like crying too -- I did some work (see
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html)
I should have also linked:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
Of course,
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
is much simpler.
Neither addresses the empty-block/object issue by trying to evaluate {} as
an object literal where today it's a block statement.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 9:24 AM, Andreas Rossberg wrote: > On 4 January 2012 17:39, Mark S. Miller wrote: > [...] > >> Style guides will probably > >> suggest to put "use strict" on top of every Harmony program to escape > >> the mess. > > > > Every sane style guide will do so. And every linting tool should by > default > > warn on the presence of any non-strict code. And every IDE should offer > to > > make the code strict if it isn't already. > > Well, I had hoped that with ES6 we have more elegant ways of opting > into Harmony than something like the "use strict" kludge. I also > thought that that was part of Dave's motivation. > For style guides targeting ES6 only code, yes. They should simply advocate opting into strict mode in some way, and the preferred choice is unlikely to be "use strict";. For ES5, or for any code that must work on pre-ES6 browsers, "use strict"; is of course the only way to opt in to strict mode. I was thinking in terms of styles guides that anyone might write in the next three years. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Make method semantic identical in classes and literals
As it stands right now there are still other more significant outstanding issues relating to both proposals that need to be addressed. As those get resolved we will make then as consistent with each other as makes sense. I think there is wide agreement that "methods" should be should be non-enumerable. There may be less agreement on whether they should be non-writable or non-configurable. Allen On Jan 4, 2012, at 4:11 AM, Herby Vojčík wrote: > It seems this is a bug in > http://wiki.ecmascript.org/doku.php?id=harmony:object_literals. In full > proposal of object literal > (http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions), > this is written: > > If a property definition has the form of a FunctionDeclaration without the > keyword function it is a non-enumerable data property definition whose name > is the function name. > > So it is non-enumerable, writable and configurable, as generally presumed for > methods. > Could it be fixed? > > Herby > > -Pôvodná správa- From: Herby Vojčík > Sent: Tuesday, January 03, 2012 9:24 PM > To: es-discuss@mozilla.org > Subject: Make method semantic identical in classes and literals > > Hello, > > overall I believe in making classes and literals as close as possible. I > think at least semantics of things they have in common should be identical. > > In http://wiki.ecmascript.org/doku.php?id=harmony:classes, this is written: > > By default, data properties define enumerable prototype properties while > method members define non-enumerable prototype properties. Members of > non-const classes default to writable and configurable. Member adjectives, > if present, override the default attributes of the property being defined. > > (I take the liberty to treat const classes as special case, so) for > (general) non-const classes, method are non-enumerable, configurable, > writable. Declaring the method itself const (whatever syntax is adopted) > probably changes it to non-configurable and non-writable. > > I deem this semantics as the right one. We are in dynamic language and want > to have our methods changeable, but non-enumerable is very nice property of > a method. And if taking the case of static away for a moment, class is not > any special thing: we can look at it as the literal describing the class's > prototype object (which it, sort-of, does). > > In http://wiki.ecmascript.org/doku.php?id=harmony:object_literals, this is > written: > > If a property definition has the form of a FunctionDeclaration without the > keyword function it is a non-enumerable, non-writable, non-configurable data > property definition whose name is the function name. This is called a method > definition. > > (For data (not methods), the literal semantics is the same as for class, > but) for methods, object literal extension treats method as fixed. I believe > they should be non-enumerable, but writable and configurable, and only > changed to fixed when explicitly stated as const (whetever syntax is > adopted), so the semantics is the same as it is for classes. > > What do you think? > > Thanks, Herby > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
On Jan 4, 2012, at 2:56 PM, Brendan Eich wrote:
> On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:
>
>> Hi,
>>
>> as I already posted in the parallel thread, there is that strawman called
>> "do expression" by dherman that does just that.
>>
>> I feel like crying when I see how powerful data constructs could be if not
>> hampered by "possible to parse as code block" ambiguity.
>
> Yes, I have felt like crying too -- I did some work (see
> https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html)
I should have also linked:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
Of course,
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
is much simpler.
Neither addresses the empty-block/object issue by trying to evaluate {} as an
object literal where today it's a block statement.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:
> Hi,
>
> as I already posted in the parallel thread, there is that strawman called "do
> expression" by dherman that does just that.
>
> I feel like crying when I see how powerful data constructs could be if not
> hampered by "possible to parse as code block" ambiguity.
Yes, I have felt like crying too -- I did some work (see
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html) on
unifying blocks and object literals, inspired by others on this list, but it
didn't pan out. It's increasingly future-hostile as we try to extend object
literals.
Trying to invert precedence so "{}" as a program source makes an empty object
instead of an empty block, IOW favoring expressions over statements, is a
breaking change. Not only for eval, but for other variants such as javascript:
URLs.
So, I've put unifying blocks and object literals on the back burner. A more
nuanced approach that doesn't break compatibility so much would be welcome, but
I don't see it.
/be
>
> Herby
>
> -Pôvodná správa- From: François REMY
> Sent: Wednesday, January 04, 2012 10:50 PM
> To: mikesam...@gmail.com ; es-discuss
> Subject: Re: Boolean shortcuts
>
>
> “You already have to.” –> If something is bad, don't change it?
>
> (1) Block expressions are not useful because you can't use them as
> expressions (=retreive their value) if you don't use “string eval”.
> (2) Object syntax is restricted because lookahead comes at a cost for parsers.
>
> This is a mess. Beginners hate it. Parsers don't like it. And yet it's still
> there...
>
> Personnaly, I would like to do something like that (and I remind an earlier
> proposal from the mailing list) :
>
> // try to create an "x" variable
> let x = try { doSomething() } catch (ex) {};
>
> or
>
> // log the value of 1+2+3+...+10
> console.log (eval { let i=10, j=0; while(i) { j+=i—; } });
>
> Now, I have to do something like that :
>
> // not as readable
> let x; try { x=doSomething() } catch (ex) {}
>
> or
>
> // bad but close in term of input
> console.log(eval("let i=10, j=0; while(i) { j+=i--; }"));
>
> // as optimized, but not as readable
> { let i=10; let j=0; while(i) { j+=i--; }; console.log(j); };
>
> The introduction of the “eval” keyword before a block has tons of other
> advantages :
>
> {}.toString(); // will now compile and return “[object Object]” from
> anywhere in the code
>
> That means I can do something like :
>
> let props = eval {
> let obj = func();
> let prop1 = getProp1(obj);
> let prop2 = getProp2(obj, prop1);
> {
> prop1: prop1,
> prop2: prop2
> }
> }
>
> Another proposed syntax, namely
>
> this.function() {} <—> (function() {}).bind(this)
>
> will now be acceptable since
>
> function() {
> return this.function(); //ASI
> {
> doSomething();
> }
>}
>
> is not allowed in ES6, there’s no syntax conflict. So, we can introduce the
> [noLineBreak] token after “function” safely.
>
> BTW, I also think we should drop labels for ES6. This will help to simplify
> syntax, too. With ES6, we should build a new syntax that’s more logical to
> use.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
Hi,
as I already posted in the parallel thread, there is that strawman called
"do expression" by dherman that does just that.
I feel like crying when I see how powerful data constructs could be if not
hampered by "possible to parse as code block" ambiguity.
Herby
-Pôvodná správa-
From: François REMY
Sent: Wednesday, January 04, 2012 10:50 PM
To: mikesam...@gmail.com ; es-discuss
Subject: Re: Boolean shortcuts
“You already have to.” –> If something is bad, don't change it?
(1) Block expressions are not useful because you can't use them as
expressions (=retreive their value) if you don't use “string eval”.
(2) Object syntax is restricted because lookahead comes at a cost for
parsers.
This is a mess. Beginners hate it. Parsers don't like it. And yet it's still
there...
Personnaly, I would like to do something like that (and I remind an earlier
proposal from the mailing list) :
// try to create an "x" variable
let x = try { doSomething() } catch (ex) {};
or
// log the value of 1+2+3+...+10
console.log (eval { let i=10, j=0; while(i) { j+=i—; } });
Now, I have to do something like that :
// not as readable
let x; try { x=doSomething() } catch (ex) {}
or
// bad but close in term of input
console.log(eval("let i=10, j=0; while(i) { j+=i--; }"));
// as optimized, but not as readable
{ let i=10; let j=0; while(i) { j+=i--; }; console.log(j); };
The introduction of the “eval” keyword before a block has tons of other
advantages :
{}.toString(); // will now compile and return “[object Object]” from
anywhere in the code
That means I can do something like :
let props = eval {
let obj = func();
let prop1 = getProp1(obj);
let prop2 = getProp2(obj, prop1);
{
prop1: prop1,
prop2: prop2
}
}
Another proposed syntax, namely
this.function() {} <—> (function() {}).bind(this)
will now be acceptable since
function() {
return this.function(); //ASI
{
doSomething();
}
}
is not allowed in ES6, there’s no syntax conflict. So, we can introduce the
[noLineBreak] token after “function” safely.
BTW, I also think we should drop labels for ES6. This will help to simplify
syntax, too. With ES6, we should build a new syntax that’s more logical to
use.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
2012/1/4 François REMY > > “You already have to.” –> If something is bad, don't change it? No. "You already have to." -> "We shouldn't reject proposals based on problems they don't introduce." ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
“You already have to.” –> If something is bad, don't change it?
(1) Block expressions are not useful because you can't use them as expressions
(=retreive their value) if you don't use “string eval”.
(2) Object syntax is restricted because lookahead comes at a cost for parsers.
This is a mess. Beginners hate it. Parsers don't like it. And yet it's still
there...
Personnaly, I would like to do something like that (and I remind an earlier
proposal from the mailing list) :
// try to create an "x" variable
let x = try { doSomething() } catch (ex) {};
or
// log the value of 1+2+3+...+10
console.log (eval { let i=10, j=0; while(i) { j+=i—; } });
Now, I have to do something like that :
// not as readable
let x; try { x=doSomething() } catch (ex) {}
or
// bad but close in term of input
console.log(eval("let i=10, j=0; while(i) { j+=i--; }"));
// as optimized, but not as readable
{ let i=10; let j=0; while(i) { j+=i--; }; console.log(j); };
The introduction of the “eval” keyword before a block has tons of other
advantages :
{}.toString(); // will now compile and return “[object Object]” from
anywhere in the code
That means I can do something like :
let props = eval {
let obj = func();
let prop1 = getProp1(obj);
let prop2 = getProp2(obj, prop1);
{
prop1: prop1,
prop2: prop2
}
}
Another proposed syntax, namely
this.function() {} <—> (function() {}).bind(this)
will now be acceptable since
function() {
return this.function(); //ASI
{
doSomething();
}
}
is not allowed in ES6, there’s no syntax conflict. So, we can introduce the
[noLineBreak] token after “function” safely.
BTW, I also think we should drop labels for ES6. This will help to simplify
syntax, too. With ES6, we should build a new syntax that’s more logical to use.
-Message d'origine-
From: Mike Samuel
Sent: Wednesday, January 04, 2012 9:17 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
2012/1/4 Herby Vojčík :
> Hi,
>
> If you must think whether you should put it in
> parentheses or not to prevent runtime error, you rather write { window:false
> } and reduce the insecurity.
You already have to.
'boolean' === typeof eval('{ window: false }')
See section 12.4 : http://es5.github.com/#x12.4
"""
12.4 Expression Statement # Ⓣ
Syntax
ExpressionStatement :
[lookahead ∉ {{, function}] Expression ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block.
"""<>___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: No code block without introductory keyword (was: Re: Booleanshortcuts)
Hello,
Brandon Eich recently mentioned do expression, so I looked them up
(http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions). It seems
they can have good use here (though it is by accident). It would verily be
possible to adopt "no { ambiguity" rule by mandating "all {} uses must
have formal introductory context, including 'no context' which implies {...}
is
a data-production use of {...}", in which case do expression would be ideal
to include a free code block anywhere it can be needed. No need to invent
new mechanism / keyword.
Herby
-Pôvodná správa-
From: Herby Vojčík
Sent: Wednesday, January 04, 2012 2:51 PM
To: François REMY ; es-discuss@mozilla.org
Subject: No code block without introductory keyword (was: Re:
Booleanshortcuts)
Hi,
what you proposed seems like a pretty good idea (at least imho).
All other uses of {...} as code block have a introductory keyword / control
structure (if, else, while, do, function), and even the newcomer {...} uses
like module and class are preceded by one. If (maybe in "strict ES6+" only)
there was the general rule of "no code block without formal introduction",
it could make parsing much more quirk-free (and it would be clearly define
that {...} without introduction is _always_ object literal (or, more
broadly, data-producing {...} (declarative curlie)) in contrast to
imperative curlie that contains some form of action to perform).
Herby
-Pôvodná správa-
From: François REMY
Sent: Wednesday, January 04, 2012 2:27 PM
To: Herby Vojčík ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
I agree that code block is a complex feature that is (almost) never used and
that has many quirks.
If ES6 could remove it, I would not be upset at all. If it's here to stay,
we should at least have an introductory keyword like "eval { ... }" and
allow "var x = eval { ... }".
BTW, I think the reason of your inconsistency is a bug : eval("{}") should
return undefined, as in IE9. It seems that node.js has a special case for
{}, probably to avoid a common mistake. Or there's a bug in the parser, I
don't know.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 9:35 AM, Allen Wirfs-Brock wrote:
> On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote:
>
>> ...
>>
>> Here's an interesting compromise I consider perfectly reasonable. We don't
>> *mandate* any ES6 code features be available in ES6 non-strict mode. But we
>> don't prohibit them either. For any ES6 features that have no dependence on
>> mode, like destructuring, we mandate that they be present in strict code,
>> and we make them normative optional (the new Appendix B category) in
>> non-strict code. Implementors are free to implement them or not in
>> non-strict mode, but if they implement them, it must mean the same thing as
>> the mandated meaning in strict code.
>
> I don't think we every contemplated forbidding implementations from extending
> non-strict modes with versions of new features ES6 features.
>
> However, your assumptions that destructuring has has no mode dependencies is
> wrong and a good example of why it is not so trivial to "include" it in
> non-strict code. Here are some of the dependencies I've already run into WRT
> formal parameter destructuring:
> using 'arguments' (or 'eval') in a formal parameter destructuring
> pattern or as a rest parameter - currently forbidden by strict mode
Destructuring opts into strict mode or rather its successor, ES.next. Harmony
rolls on this way.
> effect of multiple use of the same name - currently forbidden in strict
> mode but currently allowed in non-strict mode
Not allowed by JS1.[78]* in SpiderMonkey or Rhino -- we prefigured ES5-strict
on this, for sanity. When you use destructuring parameters in Firefox, you
cannot have duplicate parameter names *anywhere* in the parameter list.
js> function f({a,b},a){}
typein:1: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:1: function f({a,b},a){}
typein:1: ^
js> function f(b,{a,b}){}
typein:2: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:2: function f(b,{a,b}){}
typein:2: .^
js> function f({a,a},c){}
typein:3: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:3: function f({a,a},c){}
typein:3: ...^
> interaction between new formal parameter forms and non-strict mode
> arguments object
See above. Function is implicitly strict.
> how is declaration instantiation order for non-strict functions impacted
> by parameter default value expressions
See above, again.
> can the temporal dead-zone rules related to parameter default value
> expression evaluation in strict mode also apply to non-strict functions
Ditto.
> These tend to be subtle issues and the "right" answer is not always obvious.
> If different implementors decided to add the new formal parameter affordances
> to non-strict mode, without any guidance, they would likely come up with
> differing solutions to some of these issues and hence create
> imcompatabilities.
We need a normative spec, of course! But we do not need to support new features
in pre-strict-mode, indeed pre-ES6, combinations. New syntax is the opt-in!
> BTW, The simplest way to work around these issues, that I've found, would be
> to say that any function that uses any new formal parameter syntax is
> implicitly a strict mode function.
Sorry, I should have read this far. I guess the proposal was unclear enough
that people went down a bad path (at least you, probably Mark and Andreas).
Sorry about that -- the intention (at least my view of it when reviewing Dave's
draft proposal) was that new syntax opts in, and at a function granularity at
least!
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on > mode, like destructuring, we mandate that they be present in strict code, and > we make them normative optional (the new Appendix B category) in non-strict > code. Too complicated. Why not just have "one JavaScript" (modulo ES5 strict mode, whether its selection was explicit or implicit)? > Implementors are free to implement them or not in non-strict mode, but if > they implement them, it must mean the same thing as the mandated meaning in > strict code. We need interop on the web. If we let implementations vary as to whether, e.g., rest parameters require "use strict", then I predict the implementations that *do not* require "use strict" will win, and we'll have to spec normative non-optional anyway. I'm very sure developers will not want "use strict"; as a requirement. That battle has been lost already with most developers (the war goes on, but let's not refight unnecessarily). Anyway, predictions aside, I do not agree we should require "use strict" if the syntax speaks for itself. My argument is not against strict mode (the basis of Harmony!) but rather against requiring "use strict"; directives to use new features that can be expressed without incompatible meaning shifts (only with guaranteed early errors in pre-Harmony implementations). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 12:50 PM, Allen Wirfs-Brock wrote:
> On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote:
>
>> ...
>>
>> Any new Harmony syntax that presents no backward incompatibility *and* has a
>> body opts the body into the new edition, a superset of ES5-strict.
>>
>
> Including expression level bodies such a block lambda's or Dave's do { }
> expressions, if they are adopted??
Oh absolutely block lambda bodies are in Harmony > ES5-strict mode, you betcha!
Ditto generator bodies.
Class bodies, we covered. Module bodies -- in the o.p.
I like do {...} expressions, BTW -- tweeted about them today. They would be a
wafer-thin (John Cleese pseudo-French accent) addition to ES.next.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote:
> - Despite the superficial "fewer modes" mantra, it actually doesn't
> make the language simpler, but more complicated: instead of defining
> the semantics for Harmony features only for strict-mode programs, we
> now have to define many features for both modes (and mixed uses of
> both modes). I.e., there are more syntactic and semantic combinations
> to worry about.
Yes, this is a trade-off. It probably helps developers migrate, provided they
choose sane combinations. For example, Allen (private correspondence) wondered
if a function using the arguments object is evolved to have destructuring
parameters:
function f({a,b}, c) { arguments[0] = {a:3,b:4}; return [a, b] }
f({a:1,b:2}, 3);
I say anyone wanting deep aliasing (f returns [3, 4]) should suffer
disappointment. I doubt developers want such deep aliasing, and no implementor
does.
We don't get to clean the slate with JS, so making "mode walls" between
language versions may help implementors (by which I include spec writers) but
that's about it. Authors are not helped, and mode walls probably hurt (we hear).
I think we're better off working through the combinations, removing legacy
(mis-)features as we go. For example, function f above, because it uses
destructuring parameters, opts into the new language which *is* based on
ES5-strict -- so there's no arguments aliasing at all!
The general idea would be that any new syntax that doesn't create backward
compatibility problems on its face opts the containing (or following, in the
case of new syntax in function head) body into strict mode. By body I probably
mean function or program body and not just braced block.
> - Providing Harmony features in classic mode decreases the incentive
> for users to upgrade to strict mode. Is that a good thing?
See above -- Harmony > ES5-strict in the proposal and so users do upgrade to
strict mode. They just don't have to sprinkle "use strict"; string literals
expression statements around. That's a win.
> - After Dave's posting I foresaw people wanting implicit opt-in with
> other constructs, e.g. classes or uses of `import' -- and voila, we're
> already there. But even with that, you still have to rely on explicit
> opt-in (via "use strict"?) for enabling some features elsewhere.
Which features?
> As a
> result, we expect programmers to remember two separate, fairly random
> (for anybody not intimate with the history) lists of features that (1)
> require opt-in, and (2) imply opt-in. Style guides will probably
> suggest to put "use strict" on top of every Harmony program to escape
> the mess.
If the new syntax implies strict mode in the containing body, then this goes
away.
> - All this together (new features in old mode,
Nope. ;-)
> implicit opt-in,
Yup.
> explicit opt-in)
No -- "use strict"; the string literal expression-statement is meaningless
pre-ES5, ES5-strict in ES5, and redundant in Harmony code.
(BTW I still think we want a real |use strict;| pragma, to choke old
implementations.)
Now what do you say?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote:
> ...
>
> Any new Harmony syntax that presents no backward incompatibility *and* has a
> body opts the body into the new edition, a superset of ES5-strict.
>
Including expression level bodies such a block lambda's or Dave's do { }
expressions, if they are adopted??
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote:
> On 3 January 2012 21:01, Brendan Eich wrote:
>> On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
>>> On 3 January 2012 07:21, Brendan Eich wrote:
The top level is hard. The only way to be sure is to use pure lexical
scope (in Dave's proposal, use module {...}).
>>>
>>> Ah, but wrapping into modules is incompatible with having multiple
>>> script parts.
>>
>> I don't know what you mean. "Incompatible" in the sense that you cannot
>> transform multiple scripts into multiple anonymous modules?
>
> Yes.
That's a feature, in the proposal. You want the old behavior? Use
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote:
>> Your (3) seemed to say "use module" was something distinct from (and also
>> implicit in, so a part but not the whole of what is declared by) module
>> declaration syntax. It's not -- as proposed, it's an alternative to explicit
>> anonymous module{...} bracketing syntax that translates the block or body
>> enclosing the pragma to an anonymous module.
>
> Yes, I understand that. My point was that you can reformulate all
> that, for (almost) equivalent effect, by saying that "use module" is
> _not_ a module definition, but basically the same mode pragma as
> before,
Just to be clear: you mean |use version 6;| here by "mode pragma as before"?
> except that it now is implicit with every module body.
Assuming you do, then there is a difference -- see below.
> The only difference I can see with this description is its effect on
> the semantics of multi-part scripts.
Dave's proposal has
window.foo = "hi";
use module;
alert(foo);
desugar to
window.foo = "hi";
module {
alert(foo); // no early error, runs and alerts "hi"
}
which is not the same as what we were thinking of with "no global object as top
scope" enabled by a version pragma:
window.foo = "hi";
use version 6;
alert(foo); // early error here!
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
2012/1/4 Herby Vojčík :
> Hi,
>
> If you must think whether you should put it in
> parentheses or not to prevent runtime error, you rather write { window:false
> } and reduce the insecurity.
You already have to.
'boolean' === typeof eval('{ window: false }')
See section 12.4 : http://es5.github.com/#x12.4
"""
12.4 Expression Statement # Ⓣ
Syntax
ExpressionStatement :
[lookahead ∉ {{, function}] Expression ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block.
"""
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 11:29 PM, Mark S. Miller wrote:
> On Tue, Jan 3, 2012 at 10:18 PM, Brendan Eich wrote:
> On Jan 3, 2012, at 9:52 PM, Mark S. Miller wrote:
>
> > A good example. Since the class proposal uses "private, public, static",
> > by these principles, it would only be recognized in strict mode. If it
> > appears in non-strict code, it would be a SyntaxError.
>
> That's a choice. I'm asking why it's the best one. Just because class syntax
> might involve new reserved identifiers doesn't require strict mode. The
> introductory keyword is class and the new keywords are all in the braced body.
>
> The idea is that the always-reserved 'class' keyword is opt-in enough -- no
> need for a "use strict"; string litearl (ignored by old browsers anyway!).
>
> "opt-in enough", interesting. I'm not sure if this is what you meant, but it
> suggests a very attractive option I hadn't considered: treat "class", like
> "module", as yet another way to opt-in to strict mode. All code recursively
> inside a class would be strict.
Yes, that's what I meant.
Harmony > ES5-strict ES5 (> means supserset, means neither super- nor
subset).
Any new Harmony syntax that presents no backward incompatibility *and* has a
body opts the body into the new edition, a superset of ES5-strict.
> For class, you're right. I really like the idea of having it be another way
> to opt-in to strict mode. What other constructs might join "class" and
> "module" as new strict-mode opt-ins?
As Dave mentioned, generators:
function* Fibonacci() {
let [a, b] = [0, 1];
for (;;) {
yield a;
[a, b] = [b, a+b];
}
}
>
> > Want to use "let" scoping outside a module? Again, just say "use strict";.
>
> The string literal directive is meaningless in old browsers, and the other
> new syntax than let is guaranteed to fail with a syntax error in old engines,
> so what's the benefit of requiring the extra "use strinct"; again?
>
> Huh? In ES5, the following code is legal:
>
> var let = 88;
>
> The following code is not:
>
> function foo() { "use strict"; var let = 88; }
Consider instead these examples:
var let = 88;
function foo() { "use strict"; let bar = 99; }
My point was pre-ES5 implementations don't respect "use strict", so the first
line works while the second line fails with an early error due to unrecognized
'let'. As you note, ES5 implementations support the first and fail on the
second with a different early error.
Now, if ES6 implementations extend "use strict" to enable let, then suddenly
both work.
Therefore if authors face ES5 and ES6 implementations in the field, saying "use
strict" is not enough to reliably use 'let'. True, ES5 implementations will
fail with an early error -- just as they would on class or module declarations.
But they'd fail on most 'let' declarations anyway, so why should "use strict"
be required?
This is the question: if 'let' can be used reliably only in ES6 implementations
and it fails fast in pre-ES6 implementations, why insist on, or educate users
to add, "use strict" -- especially when that is not meaningful to pre-ES5
browsers, and the only difference between pre-ES5 and ES5 browsers is what kind
of early error (perhaps just the message detail) is thrown?
> I don't want to twist the grammar to turn "let" into a context sensitive
> reserved word so that somehow
>
> "var let = 88;" and use of let-scoping can co-exist in the same mode.
> This seems like too high a price to pay simply to avoid any of the strict
> mode opt ins.
Agreed, that is a bridge too far and we've said so before. Gavin B. was asking
again about it and I replied citing destructuring (let [x] = y; after another
terminated statement) as one ambiguous case.
> Any code under active maintenance should opt-in to strict somehow anyway.
You think so but developers are not doing it. Some have tried and been burned
by concatenation without testing in ES5 implementations. Others don't like the
performance effects (real but not necessarily biting them). "use strict" is not
catching on, sorry to relate, and this is why I do not think we should yoke
'let' to it.
If we don't need to predicate 'let' on "use strict" to avoid backward
incompatibility (other than in details of early error thrown), then we should
not. The destructuring ambiguity remains, but perhaps there is a solution.
Still thinking about this...
> Non-strict mode is only for legacy that needs to keep working without any
> further human attention -- most of the web. This code already doesn't use let
> scoping, so what's the issue?
There are two issues:
1. Needless "use strict" when new syntax (mostly or completely) is necessary
and sufficient opt-in by itself. We agree this is the case for class and module
-- also (I hope) for function*.
2. Lack of "use strict" adoption means coupling to it too much raises risk of
ES6 non-adoption.
> Again, the criteria I care about is "practica
Re: Boolean shortcuts
Hi,
well, it is true that if {...} is ambiguous, you can always put it in
parentheses to enforce parsing it like an expression, but it reduces the
convenience of the proposal. If you must think whether you should put it in
parentheses or not to prevent runtime error, you rather write {
window:false } and reduce the insecurity.
I had in mind some more enhancements of the object literal, but they all
would made insecure for that same reason: the code could be mistakenly
parsed as code block. Using ({...}) I can in fact always "mark as data", but
it is in fact very convenient that such marking is not needed, if it would
be, it would make things less useful. If there should be "marking" needed at
all, I think it should be there for the (free, stray) code blocks, not for
data blocks (as seen in the parallel "No code block without introductory
keyword" thread). What do you think of that?
If it would be unambigously (and conveniently) be able to tell code block
apart from data block, the data blockk could be made much more powerful (and
move even more from imperative to declarative; classes were also a move to
that way, but it could go even further).
Like in, for example, the production: { name: aName, age: anAge, if
(anAge>60) { retired: true, place: "rural" } else { place: "urban" } }. If
it is ambiguous,
{ ... } with if inside would be treated as code block, but if it would be
known that it _is_ a data block, one could put "data-if" inside without
problems.
Herby
-Pôvodná správa-
From: Mike Samuel
Sent: Wednesday, January 04, 2012 6:29 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
2012/1/4 Herby Vojčík :
Curse that eval-uation of a code block! This prevents not only this, but a
lot of more possible enhancements/reforms!
I don't see the problem. You are proposing a change to the
ObjectInitialiser production. Francois's example just demonstrates
something we already know -- that there exist strings that will parse
as an ObjectInitialiser when you start in the Expression production
but parse as a Block when you start in the Program production.
eval('{ !window }') is and would remain a block, and eval('({ !window
})') with your proposal would be unambiguously an object initialiser,
and is a SyntaxError in ES5.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > ... > > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on > mode, like destructuring, we mandate that they be present in strict code, and > we make them normative optional (the new Appendix B category) in non-strict > code. Implementors are free to implement them or not in non-strict mode, but > if they implement them, it must mean the same thing as the mandated meaning > in strict code. I don't think we every contemplated forbidding implementations from extending non-strict modes with versions of new features ES6 features. However, your assumptions that destructuring has has no mode dependencies is wrong and a good example of why it is not so trivial to "include" it in non-strict code. Here are some of the dependencies I've already run into WRT formal parameter destructuring: using 'arguments' (or 'eval') in a formal parameter destructuring pattern or as a rest parameter - currently forbidden by strict mode effect of multiple use of the same name - currently forbidden in strict mode but currently allowed in non-strict mode interaction between new formal parameter forms and non-strict mode arguments object how is declaration instantiation order for non-strict functions impacted by parameter default value expressions can the temporal dead-zone rules related to parameter default value expression evaluation in strict mode also apply to non-strict functions These tend to be subtle issues and the "right" answer is not always obvious. If different implementors decided to add the new formal parameter affordances to non-strict mode, without any guidance, they would likely come up with differing solutions to some of these issues and hence create imcompatabilities. BTW, The simplest way to work around these issues, that I've found, would be to say that any function that uses any new formal parameter syntax is implicitly a strict mode function. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
2012/1/4 Herby Vojčík :
> Curse that eval-uation of a code block! This prevents not only this, but a
> lot of more possible enhancements/reforms!
I don't see the problem. You are proposing a change to the
ObjectInitialiser production. Francois's example just demonstrates
something we already know -- that there exist strings that will parse
as an ObjectInitialiser when you start in the Expression production
but parse as a Block when you start in the Program production.
eval('{ !window }') is and would remain a block, and eval('({ !window
})') with your proposal would be unambiguously an object initialiser,
and is a SyntaxError in ES5.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 4 January 2012 17:39, Mark S. Miller wrote: > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on > mode, like destructuring, we mandate that they be present in strict code, > and we make them normative optional (the new Appendix B category) in > non-strict code. Implementors are free to implement them or not in > non-strict mode, but if they implement them, it must mean the same thing as > the mandated meaning in strict code. Hm, I don't understand what would be gained by that. You don't get rid of the spec complexity. And you risk reducing cross-browser compatibility, which is hardly a good thing. It doesn't really help the browser vendors either. I think for anything but legacy, we should avoid normative optional. >> - After Dave's posting I foresaw people wanting implicit opt-in with >> other constructs, e.g. classes or uses of `import' -- and voila, we're >> already there. But even with that, you still have to rely on explicit >> opt-in (via "use strict"?) for enabling some features elsewhere. As a >> result, we expect programmers to remember two separate, fairly random >> (for anybody not intimate with the history) lists of features that (1) >> require opt-in, and (2) imply opt-in. Style guides will probably >> suggest to put "use strict" on top of every Harmony program to escape >> the mess. > > Every sane style guide will do so. And every linting tool should by default > warn on the presence of any non-strict code. And every IDE should offer to > make the code strict if it isn't already. Well, I had hoped that with ES6 we have more elegant ways of opting into Harmony than something like the "use strict" kludge. I also thought that that was part of Dave's motivation. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Then, why not to put every feature on ES6 mode only and backporting them one by one, giving time for each backport to see if it really works and not putting effort to backport another one until the previous one is generally accepted as safe? Herby -Pôvodná správa- From: Allen Wirfs-Brock Sent: Wednesday, January 04, 2012 6:08 PM To: Andreas Rossberg Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: ... - Despite the superficial "fewer modes" mantra, it actually doesn't make the language simpler, but more complicated: instead of defining the semantics for Harmony features only for strict-mode programs, we now have to define many features for both modes (and mixed uses of both modes). I.e., there are more syntactic and semantic combinations to worry about. Yes, I'm already seeing this as I look at the working draft of the ES6 specification to see how I would have to modify it to support this new approach. Rather than working in a small number of discrete modes, each of which implies a specific set of environmental semantic rules, I have to consider pairwise interactions between features that span modes. Some initial issues I've had to look at are include the possibility of the presence of a local with scope when dealing with lexical declarations, impacts of being able to redeclare 'eval' or 'arguments', and interactions between formal parameter destructuring and non-strict mode arguments objects. If the impact was only on the spec. work this might not be a big deal, but these sorts of mode-crossing feature interactions are also visible to implementors and ES programmers and add practical and conceptual complexity that they will have to deal with. There certainly are features (for example, is and isnt) which seem to have minimal impact in any mode. But for others, there are complexities that go beyond just the syntactic compatibility issues. Modes (whether via explicit or implicit opt-in) seem to help reduce this complexity. I think Dave has pushed us down a useful path, but I also think we need to carefully semantic interactions as well as syntactic compatibility issues for each feature that we consider adding to "non-strict" code. In some cases, it may make the language easier to understand and use if features are only available in "strict mode". Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: > ... > > - Despite the superficial "fewer modes" mantra, it actually doesn't > make the language simpler, but more complicated: instead of defining > the semantics for Harmony features only for strict-mode programs, we > now have to define many features for both modes (and mixed uses of > both modes). I.e., there are more syntactic and semantic combinations > to worry about. Yes, I'm already seeing this as I look at the working draft of the ES6 specification to see how I would have to modify it to support this new approach. Rather than working in a small number of discrete modes, each of which implies a specific set of environmental semantic rules, I have to consider pairwise interactions between features that span modes. Some initial issues I've had to look at are include the possibility of the presence of a local with scope when dealing with lexical declarations, impacts of being able to redeclare 'eval' or 'arguments', and interactions between formal parameter destructuring and non-strict mode arguments objects. If the impact was only on the spec. work this might not be a big deal, but these sorts of mode-crossing feature interactions are also visible to implementors and ES programmers and add practical and conceptual complexity that they will have to deal with. There certainly are features (for example, is and isnt) which seem to have minimal impact in any mode. But for others, there are complexities that go beyond just the syntactic compatibility issues. Modes (whether via explicit or implicit opt-in) seem to help reduce this complexity. I think Dave has pushed us down a useful path, but I also think we need to carefully semantic interactions as well as syntactic compatibility issues for each feature that we consider adding to "non-strict" code. In some cases, it may make the language easier to understand and use if features are only available in "strict mode". Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 8:39 AM, Mark S. Miller wrote: > On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg wrote: > >> >> [...] > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on > mode, like destructuring, we mandate that they be present in strict code, > and we make them normative optional (the new Appendix B category) in > non-strict code. Implementors are free to implement them or not in > non-strict mode, but if they implement them, it must mean the same thing as > the mandated meaning in strict code. > Except for nested named function definitions, which already have bizarre de facto behaviors in non-strict code that no one can fix. Perhaps there are more such conflicts in legacy non-standard features? If so, we probably need to exempt them as well. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 13:23 , Andreas Rossberg wrote: > Considering all that, I can't help feeling that having a separate mode > is cleaner, simpler, and easier to use. I think it also has more > potential for providing a robust foundation for future evolution of > the language. Taking a step back from modes: What will ES6 support for legacy browsers look like? - Wouldn’t you know per piece of code/file whether it is ES5 or ES6? And make that decision (all in or all out) per browser? I still don’t completely understand why/when it would be a mixed affair. I would write minimal setup code inline and then load a module as quickly as possible. - One possibility: several versions of each file: ES3, ES5, ES6. Are there ideas for how we could either statically keep the versions and let each browser load the appropriate one or how we could dynamically compile (either server-side or client-side, possibly including caching)? This multi-version scheme could even be applied to (the JS code embedded in) HTML files. Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg wrote: > Mark's reformulation of the proposal is somewhat different from how I > initially interpreted it -- in particular, wrt tying (merging) > extended mode to strict mode. But it seems like the logical > conclusion. > > The main problem with the proposal (in both Dave's original form and > with Mark's refinement) is that it essentially gives up the idea that > Harmony builds on strict mode. It is not at all obvious to me what > implications that will have. A few observations: > > - Despite the superficial "fewer modes" mantra, it actually doesn't > make the language simpler, but more complicated: instead of defining > the semantics for Harmony features only for strict-mode programs, we > now have to define many features for both modes (and mixed uses of > both modes). I.e., there are more syntactic and semantic combinations > to worry about. > > - Providing Harmony features in classic mode decreases the incentive > for users to upgrade to strict mode. Is that a good thing? > Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. > > - After Dave's posting I foresaw people wanting implicit opt-in with > other constructs, e.g. classes or uses of `import' -- and voila, we're > already there. But even with that, you still have to rely on explicit > opt-in (via "use strict"?) for enabling some features elsewhere. As a > result, we expect programmers to remember two separate, fairly random > (for anybody not intimate with the history) lists of features that (1) > require opt-in, and (2) imply opt-in. Style guides will probably > suggest to put "use strict" on top of every Harmony program to escape > the mess. > Every sane style guide will do so. And every linting tool should by default warn on the presence of any non-strict code. And every IDE should offer to make the code strict if it isn't already. > > - All this together (new features in old mode, implicit opt-in, > explicit opt-in) makes it more subtle to see what piece of ES6 code is > strict and which isn't. This is a disadvantage when reading code and a > potential pitfall for refactoring (probably much worse than strict > mode today). > The only sensible refactoring of non-strict code is to make it strict. All other refactorings should start with that one. > > - Finally, not having a new mode restricts our ability to clean up the > language beyond what's already in strict mode (see typeof). > > Considering all that, I can't help feeling that having a separate mode > is cleaner, simpler, and easier to use. I think it also has more > potential for providing a robust foundation for future evolution of > the language. > > /Andreas > -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: No code block without introductory keyword (was: Re: Boolean shortcuts)
Hi,
I am sorry that I am so dense in my communication, I meant not only "no code
block without formal introduction", but also adding a keyword to the
repertoire that, in those rare cases of free code block (they are not really
that common), introduces a free code block. The rule of NCBWFI makes the
code really formally clearer. You see in François's example that the change
is not big (I would personally like "local" more than "eval", somehow the
old associations from the university sprung up from SML/NJ course where
local and let were coupled, so it seemed like good choice, but "local"
cannot be a keyword since it is surely used in _lots_ of places as a
variable name).
Herby
-Pôvodná správa-
From: Maël Nison
Sent: Wednesday, January 04, 2012 2:56 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss@mozilla.org
Subject: Re: No code block without introductory keyword (was: Re: Boolean
shortcuts)
If we force a formal block introduction, there will be some problems
with codes like this one :
var foo = function ( ) {
{
let x = 42;
console.log( x );
}
{
let x = 24;
console.log( x );
}
}
On 4 January 2012 14:51, Herby Vojčík wrote:
Hi,
what you proposed seems like a pretty good idea (at least imho).
All other uses of {...} as code block have a introductory keyword /
control
structure (if, else, while, do, function), and even the newcomer {...}
uses
like module and class are preceded by one. If (maybe in "strict ES6+"
only)
there was the general rule of "no code block without formal introduction",
it could make parsing much more quirk-free (and it would be clearly define
that {...} without introduction is _always_ object literal (or, more
broadly, data-producing {...} (declarative curlie)) in contrast to
imperative curlie that contains some form of action to perform).
Herby
-Pôvodná správa- From: François REMY
Sent: Wednesday, January 04, 2012 2:27 PM
To: Herby Vojčík ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
I agree that code block is a complex feature that is (almost) never used
and
that has many quirks.
If ES6 could remove it, I would not be upset at all. If it's here to stay,
we should at least have an introductory keyword like "eval { ... }" and
allow "var x = eval { ... }".
BTW, I think the reason of your inconsistency is a bug : eval("{}") should
return undefined, as in IE9. It seems that node.js has a special case for
{}, probably to avoid a common mistake. Or there's a bug in the parser, I
don't know.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Maël Nison
Epitech 2014, Paris - Astek
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: No code block without introductory keyword (was: Re: Boolean shortcuts)
If someone use ES6 features while the spec isn't done yet, he takes the risk
of having his code breaking as the specification evolve.
In this case, he would have to rewrite his code as
var foo = function() {
eval {
let x = 42;
console.log( x );
}
eval {
let x = 24;
console.log( x );
}
}
François
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
-Pôvodná správa-
From: François REMY
Sent: Wednesday, January 04, 2012 2:27 PM
To: Herby Vojčík ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
BTW, I think the reason of your inconsistency is a bug : eval("{}") should
return undefined, as in IE9. It seems that node.js has a special case for
{}, probably to avoid a common mistake. Or there's a bug in the parser, I
don't know.
===
Well, it was not really eval("..."), I ran all the expressions in the REPL
(the eval("{}") does return undefined). Though I think even in REPL (which
is implemented by compiling a piece of script In v8 and running it, not
directly though eval, but using v8 API) there should not be such
inconsistency, either...
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: No code block without introductory keyword (was: Re: Boolean shortcuts)
If we force a formal block introduction, there will be some problems
with codes like this one :
var foo = function ( ) {
{
let x = 42;
console.log( x );
}
{
let x = 24;
console.log( x );
}
}
On 4 January 2012 14:51, Herby Vojčík wrote:
> Hi,
>
> what you proposed seems like a pretty good idea (at least imho).
> All other uses of {...} as code block have a introductory keyword / control
> structure (if, else, while, do, function), and even the newcomer {...} uses
> like module and class are preceded by one. If (maybe in "strict ES6+" only)
> there was the general rule of "no code block without formal introduction",
> it could make parsing much more quirk-free (and it would be clearly define
> that {...} without introduction is _always_ object literal (or, more
> broadly, data-producing {...} (declarative curlie)) in contrast to
> imperative curlie that contains some form of action to perform).
>
> Herby
>
> -Pôvodná správa- From: François REMY
> Sent: Wednesday, January 04, 2012 2:27 PM
> To: Herby Vojčík ; es-discuss@mozilla.org
> Subject: Re: Boolean shortcuts
>
> I agree that code block is a complex feature that is (almost) never used and
> that has many quirks.
>
> If ES6 could remove it, I would not be upset at all. If it's here to stay,
> we should at least have an introductory keyword like "eval { ... }" and
> allow "var x = eval { ... }".
>
> BTW, I think the reason of your inconsistency is a bug : eval("{}") should
> return undefined, as in IE9. It seems that node.js has a special case for
> {}, probably to avoid a common mistake. Or there's a bug in the parser, I
> don't know.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Maël Nison
Epitech 2014, Paris - Astek
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
No code block without introductory keyword (was: Re: Boolean shortcuts)
Hi,
what you proposed seems like a pretty good idea (at least imho).
All other uses of {...} as code block have a introductory keyword / control
structure (if, else, while, do, function), and even the newcomer {...} uses
like module and class are preceded by one. If (maybe in "strict ES6+" only)
there was the general rule of "no code block without formal introduction",
it could make parsing much more quirk-free (and it would be clearly define
that {...} without introduction is _always_ object literal (or, more
broadly, data-producing {...} (declarative curlie)) in contrast to
imperative curlie that contains some form of action to perform).
Herby
-Pôvodná správa-
From: François REMY
Sent: Wednesday, January 04, 2012 2:27 PM
To: Herby Vojčík ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
I agree that code block is a complex feature that is (almost) never used and
that has many quirks.
If ES6 could remove it, I would not be upset at all. If it's here to stay,
we should at least have an introductory keyword like "eval { ... }" and
allow "var x = eval { ... }".
BTW, I think the reason of your inconsistency is a bug : eval("{}") should
return undefined, as in IE9. It seems that node.js has a special case for
{}, probably to avoid a common mistake. Or there's a bug in the parser, I
don't know.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
I agree that code block is a complex feature that is (almost) never used and
that has many quirks.
If ES6 could remove it, I would not be upset at all. If it's here to stay,
we should at least have an introductory keyword like "eval { ... }" and
allow "var x = eval { ... }".
BTW, I think the reason of your inconsistency is a bug : eval("{}") should
return undefined, as in IE9. It seems that node.js has a special case for
{}, probably to avoid a common mistake. Or there's a bug in the parser, I
don't know.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
Curse that eval-uation of a code block! This prevents not only this, but a
lot of more possible enhancements/reforms!
Also `{ !window }.foo` would be problematic since it will be pronounced
code-block before . is reached. :-(
Thanks for pointing out, Herby
p.s. It is really wild. In node.js, eval("{}") returns {}, eval("{;}")
returns undefined, eval("{;} 3") returns 3, but eval("{;} {}") returns
undefined (why not {}? Or why did not first eval returned undefined?);
eval("{;} ({})") returns {}, of course.
-Pôvodná správa-
From: François REMY
Sent: Wednesday, January 04, 2012 1:26 PM
To: Herby Vojčík ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts
Doesn't play nice with already existing blocks :
eval("{ !window }") // returns false;
Regards,
François
-Message d'origine-
From: Herby Vojčík
Sent: Wednesday, January 04, 2012 12:49 PM
To: es-discuss@mozilla.org
Subject: Boolean shortcuts
(original article in
http://blog.herby.sk/blosxom/Programming/ES-next/boolean-shortcut.html)
Hello, what about shorter way to express booleans?
Booleans are very nice concept, but can get bulky. That is why people may
avoid using it, sometimes. Moreover, booleans are often put inside nice
"traity" names like isRetired or done which are nice in constructs like if
(!retired) {...}. It would be nice if they could be declared using shorter,
more natural way (more descriptive) instead of using explicit true and false
value assignment (imperative). Booleans have some instrinsic non-imperative,
descriptive feel, so I'd like to be able to express it.
In literals. In literals, let it be possible to use not only foo:true and
baz:false productions (comma-terminated except the very last one), but also
simplified foo and !baz productions. This will allow for example this nice
thing:
Object.defineProperty(foo, "id", {
value: "Moo",
!enumerable, configurable, writable
});
By this I have stolen ! character from Allen Wirfs-Brock's use in literal
extension (
http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions
), but I believe ! is associated with boolean not and this use would be
more fit for it. Literals created this way (if booleans have "traity" names)
are shorter and naturally readable, so if this would be accepted for
literals only, it would be nice. Though I can envision the use of this in
the rest of boolean-value-assignment contexts, like:
In variable declarations. In variable declaration it would be nice if
instead of var done = false; it could be simply put that var !done;. I am
not proposing this for general assign (it would be awkward), only for
initialization in declaration.
This brings a sad assymetry that I can not use similar streamlined var
soFarSoGood; instead of var soFarSoGood = true;. false have its shortcut
initalization, and true does not? I do have a workaround proposal for this,
though it it less nice, but it is an idiom known to all Javascripters with
some experience. Let us allow use var !!soFarSoGood; as well. It can then be
used as a shortcut true if developer sees it fit for the situation.
The above paragraphs should of course hold for let and const declarations,
as well.
In classes. In classes (that is, in their prototypes, which are outlined by
class {...} block) the use of booleans is not very common, but for the sake
of orthogonality and not creating special cases (it is a curly block, too,
same as object literal and code block), let it be used in public declaration
akin to var above. This can allow for example creating Smalltalkish
isDuckType constructs like this:
class Animal {
public !!isAnimal;
...
});
class Ape extends Animal {
...
});
class Human extends Ape {
public !isAnimal;
public !!isPerson;
...
});
(not that it is a great use-case, but just to show there is some; I would
propose it even if I knew of none, not to create differences between {...}
constructs.)
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Boolean shortcuts
Doesn't play nice with already existing blocks :
eval("{ !window }") // returns false;
Regards,
François
-Message d'origine-
From: Herby Vojčík
Sent: Wednesday, January 04, 2012 12:49 PM
To: es-discuss@mozilla.org
Subject: Boolean shortcuts
(original article in
http://blog.herby.sk/blosxom/Programming/ES-next/boolean-shortcut.html)
Hello, what about shorter way to express booleans?
Booleans are very nice concept, but can get bulky. That is why people may
avoid using it, sometimes. Moreover, booleans are often put inside nice
"traity" names like isRetired or done which are nice in constructs like if
(!retired) {...}. It would be nice if they could be declared using shorter,
more natural way (more descriptive) instead of using explicit true and false
value assignment (imperative). Booleans have some instrinsic non-imperative,
descriptive feel, so I'd like to be able to express it.
In literals. In literals, let it be possible to use not only foo:true and
baz:false productions (comma-terminated except the very last one), but also
simplified foo and !baz productions. This will allow for example this nice
thing:
Object.defineProperty(foo, "id", {
value: "Moo",
!enumerable, configurable, writable
});
By this I have stolen ! character from Allen Wirfs-Brock's use in literal
extension (
http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions
), but I believe ! is associated with boolean not and this use would be
more fit for it. Literals created this way (if booleans have "traity" names)
are shorter and naturally readable, so if this would be accepted for
literals only, it would be nice. Though I can envision the use of this in
the rest of boolean-value-assignment contexts, like:
In variable declarations. In variable declaration it would be nice if
instead of var done = false; it could be simply put that var !done;. I am
not proposing this for general assign (it would be awkward), only for
initialization in declaration.
This brings a sad assymetry that I can not use similar streamlined var
soFarSoGood; instead of var soFarSoGood = true;. false have its shortcut
initalization, and true does not? I do have a workaround proposal for this,
though it it less nice, but it is an idiom known to all Javascripters with
some experience. Let us allow use var !!soFarSoGood; as well. It can then be
used as a shortcut true if developer sees it fit for the situation.
The above paragraphs should of course hold for let and const declarations,
as well.
In classes. In classes (that is, in their prototypes, which are outlined by
class {...} block) the use of booleans is not very common, but for the sake
of orthogonality and not creating special cases (it is a curly block, too,
same as object literal and code block), let it be used in public declaration
akin to var above. This can allow for example creating Smalltalkish
isDuckType constructs like this:
class Animal {
public !!isAnimal;
...
});
class Ape extends Animal {
...
});
class Human extends Ape {
public !isAnimal;
public !!isPerson;
...
});
(not that it is a great use-case, but just to show there is some; I would
propose it even if I knew of none, not to create differences between {...}
constructs.)
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Mark's reformulation of the proposal is somewhat different from how I initially interpreted it -- in particular, wrt tying (merging) extended mode to strict mode. But it seems like the logical conclusion. The main problem with the proposal (in both Dave's original form and with Mark's refinement) is that it essentially gives up the idea that Harmony builds on strict mode. It is not at all obvious to me what implications that will have. A few observations: - Despite the superficial "fewer modes" mantra, it actually doesn't make the language simpler, but more complicated: instead of defining the semantics for Harmony features only for strict-mode programs, we now have to define many features for both modes (and mixed uses of both modes). I.e., there are more syntactic and semantic combinations to worry about. - Providing Harmony features in classic mode decreases the incentive for users to upgrade to strict mode. Is that a good thing? - After Dave's posting I foresaw people wanting implicit opt-in with other constructs, e.g. classes or uses of `import' -- and voila, we're already there. But even with that, you still have to rely on explicit opt-in (via "use strict"?) for enabling some features elsewhere. As a result, we expect programmers to remember two separate, fairly random (for anybody not intimate with the history) lists of features that (1) require opt-in, and (2) imply opt-in. Style guides will probably suggest to put "use strict" on top of every Harmony program to escape the mess. - All this together (new features in old mode, implicit opt-in, explicit opt-in) makes it more subtle to see what piece of ES6 code is strict and which isn't. This is a disadvantage when reading code and a potential pitfall for refactoring (probably much worse than strict mode today). - Finally, not having a new mode restricts our ability to clean up the language beyond what's already in strict mode (see typeof). Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 3 January 2012 21:01, Brendan Eich wrote:
> On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
>> On 3 January 2012 07:21, Brendan Eich wrote:
>>> The top level is hard. The only way to be sure is to use pure lexical scope
>>> (in Dave's proposal, use module {...}).
>>
>> Ah, but wrapping into modules is incompatible with having multiple
>> script parts.
>
> I don't know what you mean. "Incompatible" in the sense that you cannot
> transform multiple scripts into multiple anonymous modules?
Yes.
>> For multi-part scripts we need a way to switch the
>> _proper_ top-level into extended mode. Or should I not be able to
>> write (the relevant bits of) a multi-part script in extended mode at
>> all?
>
> The proposal may have been unclear on this point: the top level would allow
> as much new syntax and semantics as can be tolerated backwards-compatibly.
> The hard cases are let, lexical scope in the free-variables-are-errors sense
> Dave described (extant globals at start of module body are imported), and any
> runtime shifts we want (completion reform, typeof null).
I suspect there may be other subtle issues, e.g., what about `const'
and local functions? [I see, Allen mentioned that already.]
In any case, even if we allow more features in classic mode, that
still doesn't give you the ability to use _all_ Harmony features for
multi-part scripts. I think we need a proper story for this.
[I just saw that later down the thread Mark proposed reusing strict
mode as an opt-in for full Harmony. I reply to that separately.]
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 3 January 2012 21:18, Brendan Eich wrote:
> On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
>
>> On 3 January 2012 07:19, Brendan Eich wrote:
>>> On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote:
>>>
In other words, I think the main points of your proposal can
essentially be rephrased to:
1) Rename "use version 6" to "use module".
2) Allow module declarations in classic mode.
> [...]
3) Make every module body start with an implicit "use module".
>>>
>>> That's not right: use module; in a pragma turns the enclosing block or body
>>> into a module {...}, in a macro-like way. Then if the module {...} is
>>> illegal in the given context (i.e., not nested immediately in another
>>> module's body), you get the same error you'd get trying to write, e.g.,
>>>
>>> if (cond) { module { /* stuff */ } }
>>
>> Hm, I don't follow. How is this related to point (3)? The body of a
>> module always is a context where module declarations are allowed.
>
> Your (3) seemed to say "use module" was something distinct from (and also
> implicit in, so a part but not the whole of what is declared by) module
> declaration syntax. It's not -- as proposed, it's an alternative to explicit
> anonymous module{...} bracketing syntax that translates the block or body
> enclosing the pragma to an anonymous module.
Yes, I understand that. My point was that you can reformulate all
that, for (almost) equivalent effect, by saying that "use module" is
_not_ a module definition, but basically the same mode pragma as
before, except that it now is implicit with every module body.
The only difference I can see with this description is its effect on
the semantics of multi-part scripts.
4) Keep the semantics of the top-level scope unaltered, even in
presence of a top-level "use module".
>>>
>>> No, see above: that turns the verbatim top level into the ... part of
>>> module {...}.
>>
>> OK, I see, but then we effectively have opted out of the global
>> object, at least as a carrier for the verbatim top-level declarations
>> of the (current) script, haven't we?
>
> No. Dave wrote "Short answer: giving up" and "You can still do it with a
> custom loader".
>
> That is, even in a module (declared at top level either implicitly via the
> |use module;| pragma or explicitly via module id? {...}), the proposal still
> keeps the global object on the scope chain. But the proposal does a free
> variable analysis based on importing the properties of the global at the
> start of the module's body, and any free variables are early errors.
Those quotes from Dave's post are exactly the bits I couldn't make
sense of properly. Because even before his proposal, I remember what
you describe being an option we were still considering. Thanks for
clarifying.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Make method semantic identical in classes and literals
It seems this is a bug in http://wiki.ecmascript.org/doku.php?id=harmony:object_literals. In full proposal of object literal (http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions), this is written: If a property definition has the form of a FunctionDeclaration without the keyword function it is a non-enumerable data property definition whose name is the function name. So it is non-enumerable, writable and configurable, as generally presumed for methods. Could it be fixed? Herby -Pôvodná správa- From: Herby Vojčík Sent: Tuesday, January 03, 2012 9:24 PM To: es-discuss@mozilla.org Subject: Make method semantic identical in classes and literals Hello, overall I believe in making classes and literals as close as possible. I think at least semantics of things they have in common should be identical. In http://wiki.ecmascript.org/doku.php?id=harmony:classes, this is written: By default, data properties define enumerable prototype properties while method members define non-enumerable prototype properties. Members of non-const classes default to writable and configurable. Member adjectives, if present, override the default attributes of the property being defined. (I take the liberty to treat const classes as special case, so) for (general) non-const classes, method are non-enumerable, configurable, writable. Declaring the method itself const (whatever syntax is adopted) probably changes it to non-configurable and non-writable. I deem this semantics as the right one. We are in dynamic language and want to have our methods changeable, but non-enumerable is very nice property of a method. And if taking the case of static away for a moment, class is not any special thing: we can look at it as the literal describing the class's prototype object (which it, sort-of, does). In http://wiki.ecmascript.org/doku.php?id=harmony:object_literals, this is written: If a property definition has the form of a FunctionDeclaration without the keyword function it is a non-enumerable, non-writable, non-configurable data property definition whose name is the function name. This is called a method definition. (For data (not methods), the literal semantics is the same as for class, but) for methods, object literal extension treats method as fixed. I believe they should be non-enumerable, but writable and configurable, and only changed to fixed when explicitly stated as const (whetever syntax is adopted), so the semantics is the same as it is for classes. What do you think? Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Boolean shortcuts
(original article in
http://blog.herby.sk/blosxom/Programming/ES-next/boolean-shortcut.html)
Hello, what about shorter way to express booleans?
Booleans are very nice concept, but can get bulky. That is why people may
avoid using it, sometimes. Moreover, booleans are often put inside nice
"traity" names like isRetired or done which are nice in constructs like if
(!retired) {...}. It would be nice if they could be declared using shorter,
more natural way (more descriptive) instead of using explicit true and false
value assignment (imperative). Booleans have some instrinsic non-imperative,
descriptive feel, so I'd like to be able to express it.
In literals. In literals, let it be possible to use not only foo:true and
baz:false productions (comma-terminated except the very last one), but also
simplified foo and !baz productions. This will allow for example this nice
thing:
Object.defineProperty(foo, "id", {
value: "Moo",
!enumerable, configurable, writable
});
By this I have stolen ! character from Allen Wirfs-Brock's use in literal
extension (
http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions
), but I believe ! is associated with boolean not and this use would be
more fit for it. Literals created this way (if booleans have "traity" names)
are shorter and naturally readable, so if this would be accepted for
literals only, it would be nice. Though I can envision the use of this in
the rest of boolean-value-assignment contexts, like:
In variable declarations. In variable declaration it would be nice if
instead of var done = false; it could be simply put that var !done;. I am
not proposing this for general assign (it would be awkward), only for
initialization in declaration.
This brings a sad assymetry that I can not use similar streamlined var
soFarSoGood; instead of var soFarSoGood = true;. false have its shortcut
initalization, and true does not? I do have a workaround proposal for this,
though it it less nice, but it is an idiom known to all Javascripters with
some experience. Let us allow use var !!soFarSoGood; as well. It can then be
used as a shortcut true if developer sees it fit for the situation.
The above paragraphs should of course hold for let and const declarations,
as well.
In classes. In classes (that is, in their prototypes, which are outlined by
class {...} block) the use of booleans is not very common, but for the sake
of orthogonality and not creating special cases (it is a curly block, too,
same as object literal and code block), let it be used in public declaration
akin to var above. This can allow for example creating Smalltalkish
isDuckType constructs like this:
class Animal {
public !!isAnimal;
...
});
class Ape extends Animal {
...
});
class Human extends Ape {
public !isAnimal;
public !!isPerson;
...
});
(not that it is a great use-case, but just to show there is some; I would
propose it even if I knew of none, not to create differences between {...}
constructs.)
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
