Colons and other annotative characters

Brendan Eich brendan at mozilla.com
Mon Nov 22 15:16:23 PST 2010


On Nov 22, 2010, at 3:08 PM, Waldemar Horwat wrote:

> On 11/22/10 10:13, Brendan Eich wrote:
>>>     { foo : G : 33 }
>> 
>> 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
> 
> Good list.  Out of those five, the only one I'd find compelling would be the first:
> 
> { foo : G : 33 }
> 
> Alternatives 0, 1, and 3 have the problems that were already well-stated.  2 has strange placement of parentheses.

Parens do hurt, I always thought so -- I find 2 the least evil of 0-3 though.


> If we're brainstorming, I'd throw out an alternative for the object initializer syntax:
> 
> {name: value}   // What we have now, for compatibility
> {name = value}  // Identical behavior to {name: value}
> {name: type = value}  // Adding a type annotation

Isn't the last ambiguous with legal JS today (well, with const, but that's not important AFAICT):

js> const T = {}
js> function f(x) { return {p: T = x}; }   
js> o = f(42)
({p:42})

ES5 strict mode is the basis for Harmony, so the assignment would be an early error, but are guard bindings required to be const?


> If we're looking at other ASCII characters for type annotations, a few other characters such as the backtick might be an option:
> 
> {name`type: value}
> {name!type: value}
> {name%type: value}
> {name~type: value}

Do you mean only for initialisers, or for all declarations. In a var x!T = v; example, he unary operator (! or ~) seems problematic here in light of ASI unless the production is restricted before the operator.

% as "mod" has some metaphorical appeal but really, these all seem like Perlish line noise compared to colon.

/be


More information about the es-discuss mailing list