On Jul 24, 2010, at 12:45 PM, Brendan Eich wrote:
> On Jul 24, 2010, at 12:39 PM, Alex Russell wrote:
>
>> On Jul 24, 2010, at 12:27 PM, Brendan Eich wrote:
>>
>>> On Jul 24, 2010, at 11:00 AM, Alex Russell wrote:
>>>
>>>> On Jul 24, 2010, at 9:21 AM, Kevin Curtis wrote:
>>>>
>>>>> Should the proposed shorter form # desugar to function or a const
>>>>> function:
>>>>> http://wiki.ecmascript.org/doku.php?id=strawman:const_functions
>>>>
>>>> Regular, plain-old function. No funky return semantics (ala some of the
>>>> closure proposals), no extra qualifiers. If you want 'em, you can pay for
>>>> 'em. The common problem "#" attempts to address is the huge verbosity of
>>>> "function", nothing more.
>>>
>>> That's not what the proposal from you and arv says :-/:
>>>
>>> http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
>>>
>>> The completion value of the statements in the braced body of a # function
>>> is the return value.
>>
>> I take the point, but again, that's to shorten things up, not to change
>> semantics where you would have otherwise added a "return".
>>
>> My apologies for being imprecise.
>
> No problem, but there's more to say about this completion value is return
> value idea. It's not a no-brainer.
Yeah, Erik and I went round-and-round on it before proposing it. The only
reason it seemed workable is that "#" is new syntax.
> Waldemar pointed out something he and other LISP hackers run into: unintended
> completion value leakage via return. This is a hazard in expression
> languages. I added the unary void operator to JS from the beginning to help
> suppress it.
>
> Another point: if the body becomes at all involved in its control flow,
> you'll want early return or something like it. If you allow return in #
> functions, now there's greater user-confusion surface because of the implicit
> return before the tail position expressions (plural).
I think the plan was to allow for "return" in # functions. Again, we went
around on this point a couple of times and I may be wrong to want auto-return.
Frankly, I'd settle for a shorter name for "return" ;-)
>>>>> I dislike the verbosity of function - though I can't help feeling #
>>>>> could be used for other ends.
>>>>>
>>>>> let dict = #{"hello": 4, "world":5}; // it's a hash/dict not an object
>>>>
>>>> So a new dictonary/map type is interesting, but it's unclear that we
>>>> really need anything like that until/unless we turn off the "delete"
>>>> operator.
>>>
>>> Why wouldn't you ever delete from a dictionary?
>>
>> Oh, you would, but if you have a new dictionary type, you can turn of
>> "delete" in regular objects and provide a new method on the dict to handle
>> that internally.
>
> We're not removing delete, so this seems like a snipe hunt. Harmony is not
> going to be gratuitously incompatible or older-edition code that should
> migrate, won't migrate, all else equal.
I'm not advocating removing delete (yet), I was just trying to outline cases in
which I could see a new Dictionary type being a hard requirement. I can't think
of others offhand.
>>> The real motivator for dictionaries is to avoid Object.prototype pollution
>>> of the dict's "in" (not "own") property namespace.
>>
>> Which sound the like the long way around just providing a form of the
>> iterator that list only the hasOwnProperty items.
>
> Iteration is not the issue, "in" testing is and "get" false hits are. We
> don't have any short getOwnPropertyValue syntax or method, and hasOwnProperty
> is painful, especially if you have to write
>
> Object.prototype.hasOwnProperty.call(dict, key)
Yeah, that's bad. Would a new dictionary type have a specialization for "in"?
Or just a method (ala Python)? If the latter, it all seems moot-ish.
>>>>> let arr = #[4,4,5] // typed array - Numbers only - contiguous memory
>>>>> block?
>>>>
>>>> How about we start with the long form for things that are currently
>>>> uncommon and shorten them when they become painfully long to use?
>>>
>>> Good in general if you can iterate quickly enough. If we can cut to the
>>> chase, even better given the cycle times among browsers and Ecma editions.
>>
>> ...which can go down if we can get the cycle times for browser versions down.
>
> Yeah, good luck with that! Not everyone is going to agree before implementing.
Not required. We just need to clear the path so folks can implement quickly.
Fast standard iterations and fast browser iterations together create a dynamic
that allows the economics of a better-functioning browser market to disseminate
new features faster than we have recently.
> Not everyone is going to implement on the same schedule.
That's cool. My comments were with a view toward better, not perfect.
> And not everyone is going to Chrome's six week release cycle (which I admire,
> btw).
>
> /be
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
