Let's replace <| with :: (was Breaking up the <|...)
Isn't it used in E4X (not that I used it or care for it; but I recall I have read somewhere :: is not usable for this reason... I would otherwise proposed it already ;-) )?
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
... //using : instead of <|, shorten Email.prototype to just Email let email = Email:"russell.leggett at gmail.com";
Basically you are saying that : becomes an expression operator. However, that creates an ambiguity (and potential backwards compatibility issues) with the use of : as a statement label designator:
Email: "ressell.leggett at gmail.com"; //already valid ES meaning Email is the label of this statement.
Yes, I thought about this potential ambiguity but thought it was no different than the potential ambiguity of block statements vs object liberals and therefore OK.
Email: "russell.leggett at gmail.com"; // label let email = Email: "russell.leggett at gmail.com"; // operator
Considering the statement form would be useless without assignment, I didn't think it would really cause confusion.
However, unless I'm overlooking something, :: would work just fine.
let email = Email :: "ressell.leggett at gmail";
I not recall why we haven't seriously considered :: as an alternative to <|. It certainly eliminates all the typography issues.
I updated my standing test case to use it: allenwb/ESnext-experiments/blob/master/ST80collections-exp7.js
It looks fine, perhaps not quite as visually distinctive as <| but it certainly eliminates all the typography issues.
I think this it it! We should replace the <| symbol with ::
Well,
Allen Wirfs-Brock wrote:
I not recall why we haven't seriously considered :: as an alternative to <|. It certainly eliminates all the typography issues.
Because we had agreed to reserve :: for guards:
On Mar 17, 2012, at 9:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I not recall why we haven't seriously considered :: as an alternative to <|. It certainly eliminates all the typography issues.
Because we had agreed to reserve :: for guards:
Yes, that's it...
It seems a shame as it would be such a good solution to this immediate problem and there may be other alternatives for guards if we ever actually have them.
Also, I'm not sure that this usage would actually preclude :: also being used by guards . :: as "prototype for" is a binary operator. "::" as a guard designator is a suffix on a binding form. It isn't clear that there would be any syntactic ambiguities in those two contexts.
let foo::bar=p::{};
Might be cognitively confusing but I don't think it would have any parsing issue. It actually doesn't even look that confusing.
On Mar 17, 2012, at 9:14 AM, Russell Leggett wrote:
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
... //using : instead of <|, shorten Email.prototype to just Email let email = Email:"russell.leggett at gmail.com";
Basically you are saying that : becomes an expression operator. However, that creates an ambiguity (and potential backwards compatibility issues) with the use of : as a statement label designator:
Email: "ressell.leggett at gmail.com"; //already valid ES meaning Email is the label of this statement.Yes, I thought about this potential ambiguity but thought it was no different than the potential ambiguity of block statements vs object liberals and therefore OK.
Email: "russell.leggett at gmail.com"; // label let email = Email: "russell.leggett at gmail.com"; // operatorConsidering the statement form would be useless without assignment, I didn't think it would really cause confusion.
consider the proposed do {} operator that has a lot of fans.
We have to account for what this will mean:
Email: (do {...break Email;...}, do { ...});
On Mar 17, 2012, at 12:31 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
On Mar 17, 2012, at 9:14 AM, Russell Leggett wrote:
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
... //using : instead of <|, shorten Email.prototype to just Email let email = Email:"russell.leggett at gmail.com";
Basically you are saying that : becomes an expression operator. However, that creates an ambiguity (and potential backwards compatibility issues) with the use of : as a statement label designator:
Email: "ressell.leggett at gmail.com"; //already valid ES meaning Email is the label of this statement.Yes, I thought about this potential ambiguity but thought it was no different than the potential ambiguity of block statements vs object liberals and therefore OK.
Email: "russell.leggett at gmail.com"; // label let email = Email: "russell.leggett at gmail.com"; // operatorConsidering the statement form would be useless without assignment, I didn't think it would really cause confusion.
consider the proposed do {} operator that has a lot of fans.
We have to account for what this will mean:
Email: (do {...break Email;...}, do { ...});
I suppose I could have a personal bias because I very rarely need to use labels, but I don't think I'm alone in that. To start with, if I were making a label, I would just put it alone on its own line. Beyond that, it's not very confusing. Am I wrong that it's not actually ambiguous?
{}
Is that an empty static block or an empty object literal? I never find myself confused.
function Foo(){}
Behaves a little differently if it's a statement vs an expression as well. I don't see why this is a grammatically or cognitively ambiguous issue.
Wouldn't it be better to use 'as' for guards? Seems more intuitive and easier to type
let A as Number = 3;
let B as Email = "xant at google.com";
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
However, it is'nt a reserved keyword. But I don't think anybody sane would use 'as' as a variable name. Additionnaly, we could also require 'use guards' like we are going to require 'use fn'.
But the more I think about it, the more I think we should version ECMAScript. It would give us much more freedom to innovate without worrying about breaking compatibility. However, I don't want to restart a debate about that: since it was already decided that it won't happen, it would probably be a waste of time.
-----Message d'origine---
On Mar 17, 2012, at 9:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I not recall why we haven't seriously considered :: as an alternative to <|. It certainly eliminates all the typography issues.
Because we had agreed to reserve :: for guards:
or we could use ::: see allenwb/ESnext-experiments/blob/master/ST80collections-exp8.js
It is easy to type and more visually distinctive than :: (although I still prefer ::)
Also, it doesn't occur frequently enough for its length to really be an issue.
François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intuitive and easier to type
let A as Number = 3; let B as Email = "xant at google.com";
class ListNode { public nextNode as ListNode; public value; // no guard }
However, it is'nt a reserved keyword. But I don't think anybody sane would use 'as' as a variable name. Additionnaly, we could also require
If I would be in the scenarios where I have some a's and b's (collections) where I would count how many a's and b's follow some consition, I would use 'as' and 'bs' as the identifier...
On 03/17/2012 01:55 PM, François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intuitive and easier to type
let A as Number = 3; let B as Email = "xant at google.com";
class ListNode { public nextNode as ListNode; public value; // no guard }
However, it is'nt a reserved keyword. But I don't think anybody sane would use 'as' as a variable name. Additionnaly, we could also require 'use guards' like we are going to require 'use fn'.
I'm pretty sure most mainly Haskell programmers doing JS would think
about using as' (andbs', cs', ...,xs') as identifiers almost
naturally. And I guess they would also feel it natural to use `::' for
guards. But well, this is not Haskell :3
Well, using 'a' as an identifier is already bad practice. Using 'as' has a plural form of 'a' seems even worse. But, well, okay, if it happens in reality, it happens, I can't say anything else about that.
-----Message d'origine---
On Sun, 18 Mar 2012 14:09:47 +0100, François REMY <fremycompany_pub at yahoo.fr> wrote:
Well, using 'a' as an identifier is already bad practice. Using 'as' has a plural form of 'a' seems even worse. But, well, okay, if it happens in reality, it happens, I can't say anything else about that.
I don't really see that as an issue. Frequently I would love to use "class" as an identifier (I'm writing a game). Just because it isn't reserved doesn't mean we shouldn't use it, IMO. I think "x as String" would be great.
If there is a pragma for guards it makes even more sense.
On 17 March 2012 17:26, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
Also, I'm not sure that this usage would actually preclude :: also being used by guards . :: as "prototype for" is a binary operator. "::" as a guard designator is a suffix on a binding form. It isn't clear that there would be any syntactic ambiguities in those two contexts.
let foo::bar=p::{};
That is not a future-proof assumption, because it is quite natural to allow guards on arbitrary expressions:
unguardedfoo(arg :: bar)
Also, with destructuring, you'll most likely have guards on subpatterns, so the cover grammar has to handle them already.
In any case, I would find overloading the '::' notation like that too confusing.
(OTOH, I'd prefer finding a way to do guards with single ':'... :-) )
Andreas Rossberg wrote:
(OTOH, I'd prefer finding a way to do guards with single ':'... :-) )
I started there too (ES4, ML which was used [SML] for the ES4 reference implementation, other work such as Links). But TC39 argued about it and the desire to guard property names in object literals led us to favor ::.
let guardedObj = {p1::t1: v1, ~~~ pN::tN: vN};
Using : is ambiguous (using :, a property assignment, assuming optional guards, could have p:t or p:v or p:t:v). I suggested requiring parenthesization:
let guardedObj = {(p1:t1): v1 ~~~ (pN:tN): vN};
but no one liked that! Since :: was only twice as bad as :, and Haskell used it, we agreed to :: for guards.
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
Basically you are saying that : becomes an expression operator. However, that creates an ambiguity (and potential backwards compatibility issues) with the use of : as a statement label designator:
However, unless I'm overlooking something, :: would work just fine.
let email = Email :: "ressell.leggett at gmail";
I not recall why we haven't seriously considered :: as an alternative to <|. It certainly eliminates all the typography issues.
I updated my standing test case to use it: allenwb/ESnext-experiments/blob/master/ST80collections-exp7.js
It looks fine, perhaps not quite as visually distinctive as <| but it certainly eliminates all the typography issues.
I think this it it! We should replace the <| symbol with ::
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote: > ... > //using : instead of <|, shorten Email.prototype to just Email > let email = Email:"russell.leggett at gmail.com"; Basically you are saying that : becomes an expression operator. However, that creates an ambiguity (and potential backwards compatibility issues) with the use of : as a statement label designator: Email: "ressell.leggett at gmail.com"; //already valid ES meaning Email is the label of this statement. However, unless I'm overlooking something, :: would work just fine. let email = Email :: "ressell.leggett at gmail"; I not recall why we haven't seriously considered :: as an alternative to <|. It certainly eliminates all the typography issues. I updated my standing test case to use it: https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp7.js It looks fine, perhaps not quite as visually distinctive as <| but it certainly eliminates all the typography issues. I think this it it! We should replace the <| symbol with :: Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120317/8df99a80/attachment.html>