Allen's lambda syntax proposal
Eric Suen
eric.suen.tech at gmail.com
Wed Dec 3 18:57:03 PST 2008
It even can be writen as:
Lambda ::= '&' IdentifierOpt ParametersOpt Block
IdentifierOpt ::= %Empty
| PropertyIdentifier
ParametersOpt ::= %Empty
| '(' Parameters ')'
>I suggest following grammar:
>
> Lambda ::= '&' '(' Parameters ')' Block
> | '&' Block //if no parameters
>
> I can comfire that this rule is no problem for a LALR(k) parser,
> ES4 is not LALR(1) anyway. and I think ^ is not good for eyes, it
> is too small and may confused with ~. & look more like C/C++ style
>
> a = & { ... }
>
> a = & (a,b) { ... }
>
>> Yuh-Ruey Chen wrote:
>>> Brendan Eich wrote:
>>>> C# uses (a, b, c) => ... but in JS the comma operator makes that
>>>> nasty to parse top-down. I think the only candidates have to be of
>>>> the form
>>>>
>>>> ^(a, b, c) {...}
>>>>
>>>> (^ could be another character, but it seems to beat \ as others have
>>>> noted), or else the Smalltalky
>>>>
>>>> { |a, b, c| ... }
>>>>
>>>> At this point we need a bake-off, or a convincing argument against
>>>> the unusual vertical bar usage.
>>>
>>> Here's a possible technical issue that might not apply to ES: Ruby
>>> blocks params can't have default arguments according to
>>> http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
>>>
>>> The new syntax allows to specify default values for block
>>> arguments, since
>>>
>>> {|a,b=1| ... }
>>>
>>>
>>> is said to be impossible with Ruby's current LALR(1) parser, built
>>> with bison.
>>>
>>
>> That Ruby 1.9 page also lists yet another possible syntax:
>>
>> ->(a, b, ...) {...}
>>
>> Using Maciej's examples:
>>
>> if_ (->{x < 3}, ->{
>> handleSmallNum(x);
>> }, ->{
>> handleLargeNum(x);
>> });
>>
>> while_ (->{x != null}, ->{
>> x.process();
>> x = x.next();
>> });
>>
>> for_ (->{var i = 1}, ->{i < 10}, ->{i++}, ->{
>> total += vec[i];
>> });
>>
>> forIn_ (obj, ->(prop) {
>> props.push(prop);
>> });
>>
>> arr.sort(->(a, b) { a*a < b*b });
>> arr.map(->(x) { x * (x-1)});
>>
>> function doubleBs(str) {
>> str.replace(/b*/, ->(substr) { substr + substr });
>> }
>>
>> The control abstractions just don't look right, regardless of which
>> lambda syntax we choose. I'd rather wait for a more powerful macro
>> system, instead of choosing the syntax based off how it would look in
>> control abstractions.
>>
More information about the Es-discuss
mailing list