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