On Nov 22, 2010, at 5:42 AM, Mark S. Miller wrote:
> On Mon, Nov 22, 2010 at 1:09 AM, Brendan Eich <[email protected]> wrote:
> [...] Before reaching in a reactive way for @, let's slow down and consider
> what got us here: over-eager bikeshedding of : instead of "in" [...]
>
> That's not what got me here. For me the issue is uniformity of guard syntax
> across all contexts where we need them -- including properties of object
> literals. I agree it is the uncommon case. But the non-uniformity of using
> one syntax for this case and another syntax for the more common cases bugs
> me. Likewise, the technically unambiguous
>
> { foo : G : 33 }
>
> I find too visually confusing and ugly.
Agreed. My point in reply to Peter was that it may be formally unambiguous, but
it's still "ugly and confusing".
> As you are fond of saying, notation is user interface.
And how! But doubling a colon is not better interface. Especially when that
double-tax hits all declarations, not just object initialisers.
Let's see if I can write down some alternatives and list trade-offs:
0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
1. let typedObj = { foo :: G : 33 }; // the guards strawman
2. let typedObj = { (foo : G) : 33 }; // the ML-ish way
3. let typedObj = { foo @ G : 33 }; // funny cartoon chars
Trade-offs:
0+ avoids running type^H^H^H^Hguard together with property name and value using
:, ::, @, or whatever, instead paralleling the whole initialiser
0+ allows commoning the guard initialiser expression so it can be reused among
multiple object value initialisers
0- parallel structure duplicates all property names (and order? not clear),
which is tedious at any scale and error-prone for large initialisers
1+ avoids restating names (and order?)
1- imposes double-colon tax on all annotation contexts, even though only this
one wants it for visual distinctiveness (not disambiguation of formal grammar)
1- :: is an eyesore (yet arguably not distinct enough from single : -- see last
1- item), and has quite different precedent as namespace qualification operator
in Ecma and other standards
2+ keeps : as annotation punctuator
2- at the price of parenthesizing the property name in object initialisers
3+ avoids overloading colon in object initialisers
3- flouts programming language (including JS derivatives) precedent for using :
as annotation punctuator
3- may collide with JScript's preprocessor, also may collide with @attributes
in E4X, uses up @ in a novel way where we might want to reserve it for another
use
Comments:
We don't have too many other funny chars (# is wanted for concise function
syntax). This suggests trying to use : and not breaking the common annotation
case over this initialiser hard case.
Sometimes a (commoned, reusable) annotation at the end of the whole object
initialiser is pure win. It's really not clear at this point that *only* at the
end, or *only* interspersed guards, are the one way we should standardize.
If guards are uncommon in object initialisers, parenthesization is arguably
fine, not only as a tax users can pay but as a visual flag that something is up.
Let's consider the likely far more common use-cases:
var x : T = v;
function f(a: U, b: V): W {...}
... { ... let x : T = v; ... }
while @ or another char could work, the tradition favoring : combined with the
scarcity of unused punctuators makes me want to stick with colon. That, plus
the relative rarity of annotated initialisers (in my best guess -- we can argue
about this or try to estimate by adding guards to existing code), make me still
favor (2).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
