https://github.com/dlang/phobos/pull/3882

I just closed with some regret a nice piece of engineering. Please comment if you think string lambdas have a lot of unexploited potential.

One thing we really need in order to 100% replace string lambdas with lambdas is function equivalence. Right now we're in the odd situation that SomeTemplate!((a, b) => a < b) has distinct types, one per instantiation.


Andrei

On Tuesday, 26 April 2016 at 17:58:22 UTC, Andrei Alexandrescu wrote:
> One thing we really need in order to 100% replace string lambdas with lambdas is function equivalence.

One significant - but undocumented - feature of unaryFun and binaryFun, is that they will auto-import the following modules if needed:

    import std.traits, std.typecons, std.typetuple;
    import std.algorithm, std.conv, std.exception, std.math, std.range, std.string;

Does anyone actually use this feature?

On Tuesday, April 26, 2016 13:58:22 Andrei Alexandrescu via Digitalmars-d wrote:
> https://github.com/dlang/phobos/pull/3882
>
> I just closed with some regret a nice piece of engineering. Please comment if you think string lambdas have a lot of unexploited potential.

Well, they're nicer than the "new" lambda syntax for really short stuff like "a == b" or "a != b", but beyond that, the newer syntax mostly does what the string lambdas were trying to do. And if your lambda gets very long, it really should be replaced with something like a nested function anyway. Pretty much anything complicated shouldn't be a lambda, or it risks being unmaintainable. So, while that PR was indeed a nice piece of engineering, it seems to be solving a problem that really shouldn't be solved with lambdas anyway.

> One thing we really need in order to 100% replace string lambdas with lambdas is function equivalence. Right now we're in the odd situation that SomeTemplate!((a, b) => a < b) has distinct types, one per instantiation.

Once that's solved, we can consider deprecating string lambdas, but equivalence is indeed the one killer feature that non-string lambdas lack. However, from what I recall of discussions on that, it sounded like it was going to be pretty nasty to implement. :(

- Jonathan M Davis

On Tuesday, 26 April 2016 at 17:58:22 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/3882
>
> I just closed with some regret a nice piece of engineering. Please comment if you think string lambdas have a lot of unexploited potential.

I'm of the opinion that string lambdas must go. I started, and I really should finish it at some point, removing string lambdas from the documentation: https://github.com/dlang/phobos/pull/3800

I think that the drawback you mentioned does not outweigh the benefits gained from using actual lambdas.

On 04/26/2016 03:45 PM, Jack Stouffer wrote:
> I think that the drawback you mentioned does not outweigh the benefits
> gained from using actual lambdas.

Actually it turns out to be a major usability issue. -- Andrei

On 4/27/16 8:31 AM, Andrei Alexandrescu wrote:
> On 04/26/2016 03:45 PM, Jack Stouffer wrote:
>> I think that the drawback you mentioned does not outweigh the benefits
>> gained from using actual lambdas.
>
> Actually it turns out to be a major usability issue. -- Andrei

Yes, consider that RedBlackTree!(int, (a, b) => a > b) is going to be a different type every time you use it, even if they are 1 line apart!

There are actually 2 things the string lambdas have going for them: 1) common instantiation for every usage, and 2) avoiding parentheses with instantiation (impossible to do with a short lambda syntax).

I'd still vote for them to go, but we MUST fix the issue with common instantiation first.

There has been some discussion in general of using hashing to decrease the symbol size for templates, and some discussion about allowing the compiler to merge identical binary functions to reduce the size of the binaries. Both of those could play in nicely here.

-Steve

On Tuesday, 26 April 2016 at 17:58:22 UTC, Andrei Alexandrescu wrote:
> One thing we really need in order to 100% replace string lambdas with lambdas is function equivalence. Right now we're in the odd situation that SomeTemplate!((a, b) => a < b) has distinct types, one per instantiation.

Well, SomeTemplate!((a, b) => a < b) uses pass by name, so it's sort of expected to be a distinct type for each different object you pass to it. Do you want to bind different lambdas (matching by some notion of equality) to the same symbol? That'd be an enormous hack.

Now, if this was:
SomeTemplate(FunctorType) // type parameter, not alias here
{
this(FunctorType f){
...
}
...
}

and (a, b)=> a < b returned an object of the same type for equivalent functions you could have fn equality without giving different objects the same symbol. It's also inlineable as pass by name is.

On 04/27/2016 11:44 AM, Steven Schveighoffer wrote:
> On 4/27/16 8:31 AM, Andrei Alexandrescu wrote:
>> On 04/26/2016 03:45 PM, Jack Stouffer wrote:
>>> I think that the drawback you mentioned does not outweigh the benefits
>>> gained from using actual lambdas.
>>
>> Actually it turns out to be a major usability issue. -- Andrei
>
> Yes, consider that RedBlackTree!(int, (a, b) => a > b) is going to be a
> different type every time you use it, even if they are 1 line apart!
>
> There are actually 2 things the string lambdas have going for them: 1)
> common instantiation for every usage, and 2) avoiding parentheses with
> instantiation (impossible to do with a short lambda syntax).
>
> I'd still vote for them to go, but we MUST fix the issue with common
> instantiation first.
>
> There has been some discussion in general of using hashing to decrease
> the symbol size for templates, and some discussion about allowing the
> compiler to merge identical binary functions to reduce the size of the
> binaries. Both of those could play in nicely here.

Yes, you get it exactly right. I think a DIP would be warranted here to clarify how lambda equivalence is computed. Could you please draft one? -- Andrei

On Wednesday, 27 April 2016 at 12:31:18 UTC, Andrei Alexandrescu wrote:
> On 04/26/2016 03:45 PM, Jack Stouffer wrote:
>> I think that the drawback you mentioned does not outweigh the benefits
>> gained from using actual lambdas.
>
> Actually it turns out to be a major usability issue. -- Andrei

That would be better for this to go forward in a sensible manner that you explains what is the major usability issue here.

On Tuesday, 26 April 2016 at 17:58:22 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/3882
>
> I just closed with some regret a nice piece of engineering. Please comment if you think string lambdas have a lot of unexploited potential.
>
> One thing we really need in order to 100% replace string lambdas with lambdas is function equivalence. Right now we're in the odd situation that SomeTemplate!((a, b) => a < b) has distinct types, one per instantiation.
>
>
> Andrei

This can be worked around by defining a less function and using it here. This, however, runs into some subtleties because functions and functions aren't the same thing in D (Confusing ? You bet it is !).