Future of string lambda functions/string predicate functions

[Dmitry Olshansky]

14-Aug-2013 21:17, Andrei Alexandrescu пишет:
> On 8/14/13 10:15 AM, Dmitry Olshansky wrote:
>> 14-Aug-2013 20:37, H. S. Teoh пишет:
>>> On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:
>> [snip]
>>> It just occurred to me, that perhaps what we really need here is an
>>> even more abbreviated form of lambda literals, like this:
>>>
>>>     sort!(a < b)(range);
>>>
>>> where 'a' and 'b' are undefined identifiers in the current scope, and
>>> the compiler would know to bind them to lambda parameters. Defined
>>> identifiers would, naturally, bind to whatever they refer to:
>>>
>>
>> Make that
>> sort!( _ < _ )(range)
>>
>> and you have some Scala :)
>
> Really? How does Scala figure that _ < _ refers to two arguments and not
> one?

Looking into "Programming in Scala, 2nd edition" again...

Left to right, each underscore is a new parameter.
Once you need the argument 2 times you are screwed and go back to the 
same syntax we have.

Even more funny is that Scala can't bind templated parameters...
val f = _ + _

Not going to fly since there is no context to infer argument types!
Hence the crufty:
val f = ( _ : Int) + ( _ : Int)

In D:
alias f = _ + _;

Could work since with a bit of compiler magic (expression alias).
Or even
alias f = typeof(_ + _);
with expression templates. Sounds like a solution but that would destroy 
the easy ordering of arguments...

>
> Andrei
>


-- 
Dmitry Olshansky