On Nov 22, 2010, at 5:42 AM, Mark S. Miller wrote: > On Mon, Nov 22, 2010 at 1:09 AM, Brendan Eich <bren...@mozilla.com> 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss