simple shorter function syntax

[Brendan Eich]

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.

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 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.


>> 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)


>>>> 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 everyone is going to implement on the same schedule. And not everyone is going to Chrome's six week release cycle (which I admire, btw).

/be