August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 8/14/13 7:34 AM, H. S. Teoh wrote:
> On Wed, Aug 14, 2013 at 09:10:37AM +0200, Tyler Jameson Little wrote:
>> On Wednesday, 14 August 2013 at 05:44:50 UTC, Brad Anderson wrote:
>>> On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
>>>> Can you give an example where you've actually used a string lambda
>>>> before where the predicate is more complex than a basic comparison?
>>>> Surely the solution to this problem is to offer a bunch of templates
>>>> that perform the most common predicates in place of unary/binaryFun?
>>>>
>>>> So rather than: func!((a, b) => a < b)(args)
>>>> You use: func!binaryLess(args)
>>>>
>>>> Or something like that?
>>>>
>>>
>>> How about just "less"? It's what C++ STL uses (std::less,
>>> std::greater, std::negate, etc...). In C++, however, you have to
>>> do some truly ugly stuff to actually make use of the predefined
>>> function objects...bind1st...eww (the new C++11 bind is only
>>> marginally better but C++11 does have lambdas now at least).
> [...]
>> Or imitate bash:
>>
>> Binary:
>> - gt: a > b
>> - ge: a >= b
>> - lt: a < b
>> - le: a <= b
>> - eq: a == b
>> - ne: a != b
>>
>> Unary:
>> - z: (zero) a == 0 (if range, a.empty?)
>> - n: (non-zero) a != 0
>>
>> Perhaps this is *too* terse?
>
> That's a bit too terse. What about this:
>
> less // a < b
> less!(5) // a < 5
> lessEq // a <= b
> lessEq!(5) // a <= 5
> more // a > b
> more!(5) // a > 5
> moreEq // a >= b
> moreEq!(5) // a >= 5
> equal // a == b
> equal!(5) // a == 5
> notEqual // a != b
> notEqual!(5) // a != 5
At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.
Andrei
|
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote: > On 8/14/13 7:34 AM, H. S. Teoh wrote: [...] > >That's a bit too terse. What about this: > > > > less // a < b > > less!(5) // a < 5 > > lessEq // a <= b > > lessEq!(5) // a <= 5 > > more // a > b > > more!(5) // a > 5 > > moreEq // a >= b > > moreEq!(5) // a >= 5 > > equal // a == b > > equal!(5) // a == 5 > > notEqual // a != b > > notEqual!(5) // a != 5 > > At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive. [...] 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: int x = 5; find!(a == x)(range); This would be equivalent to: int x = 5; find!((a) => a==x)(range); IOW, an expression that references undefined identifiers in a template parameter would be turned into a lambda that parametrize said identifiers. T -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth |
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
> On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:
>> On 8/14/13 7:34 AM, H. S. Teoh wrote:
> [...]
>> >That's a bit too terse. What about this:
>> >
>> > less // a < b
>> > less!(5) // a < 5
>> > lessEq // a <= b
>> > lessEq!(5) // a <= 5
>> > more // a > b
>> > more!(5) // a > 5
>> > moreEq // a >= b
>> > moreEq!(5) // a >= 5
>> > equal // a == b
>> > equal!(5) // a == 5
>> > notEqual // a != b
>> > notEqual!(5) // a != 5
>>
>> At this point using "a < b" for a < b, "a < 5" for a < 5 etc.
>> becomes awfully attractive.
> [...]
>
> 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:
>
> int x = 5;
> find!(a == x)(range);
>
> This would be equivalent to:
>
> int x = 5;
> find!((a) => a==x)(range);
>
> IOW, an expression that references undefined identifiers in a template
> parameter would be turned into a lambda that parametrize said
> identifiers.
>
>
> T
That's a bit too fragile IMO.
int b; //rename to 'a'
// lots of intermediate code...
int x = 5;
r.blah!(a == x);
Renaming of a seemingly unrelated variable would result in spooky action-at-a-distance behaviour.
|
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On Wed, Aug 14, 2013 at 07:03:32PM +0200, John Colvin wrote: > On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote: > >On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote: > >>On 8/14/13 7:34 AM, H. S. Teoh wrote: > >[...] > >>>That's a bit too terse. What about this: > >>> > >>> less // a < b > >>> less!(5) // a < 5 > >>> lessEq // a <= b > >>> lessEq!(5) // a <= 5 > >>> more // a > b > >>> more!(5) // a > 5 > >>> moreEq // a >= b > >>> moreEq!(5) // a >= 5 > >>> equal // a == b > >>> equal!(5) // a == 5 > >>> notEqual // a != b > >>> notEqual!(5) // a != 5 > >> > >>At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive. > >[...] > > > >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: > > > > int x = 5; > > find!(a == x)(range); > > > >This would be equivalent to: > > > > int x = 5; > > find!((a) => a==x)(range); > > > >IOW, an expression that references undefined identifiers in a template parameter would be turned into a lambda that parametrize said identifiers. > > > > > >T > > That's a bit too fragile IMO. > > int b; //rename to 'a' > // lots of intermediate code... > int x = 5; > r.blah!(a == x); > > Renaming of a seemingly unrelated variable would result in spooky action-at-a-distance behaviour. Arguably, naming a variable as 'b' or 'a' is a bad idea, but, point taken. I guess we still have to fall back to full-fledged lambda literals, then. I'm still in favor of deprecating string lambdas, but as Andrei said, we need to address the problem of how to compare lambdas meaningfully. The question then becomes, what do we do *now*, for new additions to Phobos? Should new code still support string lambdas or not? T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before. |
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 :) > int x = 5; > find!(a == x)(range); > > This would be equivalent to: > > int x = 5; > find!((a) => a==x)(range); > > IOW, an expression that references undefined identifiers in a template > parameter would be turned into a lambda that parametrize said > identifiers. > > > T > -- Dmitry Olshansky |
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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?
Andrei
|
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote:
> 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...
And here one should probably stop for a while and ask: "is it worth it?"
|
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 8/14/2013 11:21 AM, Dicebot wrote:
> On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote:
>> 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...
>
> And here one should probably stop for a while and ask: "is it worth it?"
+1 for common sense.
|
August 14, 2013 Re: Future of string lambda functions/string predicate functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 14-Aug-2013 22:21, Dicebot пишет: > On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote: >> 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... > > And here one should probably stop for a while and ask: "is it worth it?" As a library - of course, it's a great exercise at futility. C++ Boost lambda was full of it as they had less powerful language. -- Dmitry Olshansky |
Copyright © 1999-2021 by the D Language Foundation