On Thu, Aug 08, 2013 at 09:52:05AM -0700, Jonathan M Davis wrote:
> On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
> > Seems this thread has quietened down. So, what is the conclusion? Seems like almost everyone concedes that silent deprecation is the way to go.  We still support string lambdas in the background, but in public docs we promote the use of the new lambda syntax. Would that be a fair assessment of this discussion?
> 
> I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.
[...]

Well, it would be nice of the rest of the Phobos devs speak up, otherwise they are giving the wrong impression about the state of things.


T

-- 
Many open minds should be closed for repairs. -- K5 user

On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
> Seems this thread has quietened down. So, what is the conclusion? Seems like almost everyone concedes that silent deprecation is the way to go. We still support string lambdas in the background, but in public docs we promote the use of the new lambda syntax. Would that be a fair assessment of this discussion?

I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.

> What about new Phobos functions? Should we continue to support string lambdas in new code?

Personally, I don't think that silent deprecation is ever a good idea. If we do that, we're going to end up with confusion over which functions accept strings and which don't, and it won't be clear that we're trying to get rid of them. I think that we need to clearly choose one path or the other: either

1. Choose to keep string lambdas around permanently and support them, even if they're used for a limited number of use cases (e.g. with simple lambdas which use operators but not function calls).

or

2. Put them on the path to deprecation towards removal (in which case, they might actually stay marked as deprecated for quite some time to come but would clearly be unacceptable for new code and might be fully removed at some point in the future).

- Jonathan M Davis

On 8/8/13 9:52 AM, Jonathan M Davis wrote:
> On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
>> Seems this thread has quietened down. So, what is the conclusion? Seems
>> like almost everyone concedes that silent deprecation is the way to go.
>> We still support string lambdas in the background, but in public docs we
>> promote the use of the new lambda syntax. Would that be a fair
>> assessment of this discussion?
>
> I find it interesting that very few Phobos devs have weighed in on the matter,
> but unfortunately, most of the posters who have weighed in do seem to be
> against keeping them.

There's a related issue that I think we must solve before deciding whether or not we should deprecate string lambdas. Consider:

void main() {
    import std.range;
    SortedRange!(int[], "a > b") a;
    SortedRange!(int[], "a > b") b;
    b = a;
    SortedRange!(int[], (a, b) => a > b) c;
    SortedRange!(int[], (a, b) => a > b) d;
    d = c;
}

The last line fails to compile because D does not currently have a good notion of comparing lambdas for equality. In contrast, string comparison is well defined, and although string lambdas have clowny issues with e.g. "a>b" being different from "a > b", people have a good understanding of what to do to get code working.

So I think we should come up with a good definition of what comparing two function aliases means.


Andrei

On Saturday, 10 August 2013 at 18:28:29 UTC, Jonathan M Davis wrote:
> I find it interesting that very few Phobos devs have weighed in on the matter,
> but unfortunately, most of the posters who have weighed in do seem to be
> against keeping them.

I am not actively participating in any NG discussions right now due to university work, but for the record, I am very much in favor of phasing out string lambdas as well (even if short-term removal is certainly not possible at this point).

I am sure all the relevant arguments have been brought up already, so I am not going to repeat them all over again, but in my opinion, the increased cognitive load for the user (a new syntax to learn) and the fact that string lambdas can't work for any cases involving free functions (std.functional importing half of Phobos just in case a string lambda could need a certain function clearly isn't a scalable solution) are more than enough a reason to ditch them.

String lambdas were a brilliant hack back then, but now that we have a proper solution, it's time to let them go.

David

On Sunday, 11 August 2013 at 16:26:16 UTC, Andrei Alexandrescu wrote:
> On 8/8/13 9:52 AM, Jonathan M Davis wrote:
>> On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
>>> Seems this thread has quietened down. So, what is the conclusion? Seems
>>> like almost everyone concedes that silent deprecation is the way to go.
>>> We still support string lambdas in the background, but in public docs we
>>> promote the use of the new lambda syntax. Would that be a fair
>>> assessment of this discussion?
>>
>> I find it interesting that very few Phobos devs have weighed in on the matter,
>> but unfortunately, most of the posters who have weighed in do seem to be
>> against keeping them.
>
> There's a related issue that I think we must solve before deciding whether or not we should deprecate string lambdas. Consider:
>
> void main() {
>     import std.range;
>     SortedRange!(int[], "a > b") a;
>     SortedRange!(int[], "a > b") b;
>     b = a;
>     SortedRange!(int[], (a, b) => a > b) c;
>     SortedRange!(int[], (a, b) => a > b) d;
>     d = c;
> }
>
> The last line fails to compile because D does not currently have a good notion of comparing lambdas for equality. In contrast, string comparison is well defined, and although string lambdas have clowny issues with e.g. "a>b" being different from "a > b", people have a good understanding of what to do to get code working.
>
> So I think we should come up with a good definition of what comparing two function aliases means.
>
>
> Andrei

Correct me if I'm wrong, but AFAICT the old behavior was an undocumented feature. I couldn't find string lambdas formally documented anywhere, but lambdas are.

Comparing function aliases is an optimization, not a feature, so I don't feel it's a blocker to deprecating string lambdas. If the user needs the old behavior, he/she can do this today with an actual function:

    bool gt(int a, int b) {
        return a > b;
    }

    void main() {
        import std.range;
        SortedRange!(int[], "a > b") a;
        SortedRange!(int[], "a > b") b;
        b = a;
        SortedRange!(int[], gt) c;
        SortedRange!(int[], gt) d;
        d = c;
    }

While not as concise, this is safer and does not rely on undocumented behavior.

Another consideration, are the following equivalent?

    (a,b) => a > b
    (b,c) => b > c

On 8/11/2013 9:26 AM, Andrei Alexandrescu wrote:
> There's a related issue that I think we must solve before deciding whether or
> not we should deprecate string lambdas. Consider:
>
> void main() {
>      import std.range;
>      SortedRange!(int[], "a > b") a;
>      SortedRange!(int[], "a > b") b;
>      b = a;
>      SortedRange!(int[], (a, b) => a > b) c;
>      SortedRange!(int[], (a, b) => a > b) d;
>      d = c;
> }
>
> The last line fails to compile because D does not currently have a good notion
> of comparing lambdas for equality.

Bugzilla?

On 8/8/2013 10:02 AM, H. S. Teoh wrote:
> Well, it would be nice of the rest of the Phobos devs speak up,
> otherwise they are giving the wrong impression about the state of
> things.

See Andrei's reply.

On Sun, Aug 11, 2013 at 09:26:17AM -0700, Andrei Alexandrescu wrote:
> On 8/8/13 9:52 AM, Jonathan M Davis wrote:
> >On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
> >>Seems this thread has quietened down. So, what is the conclusion? Seems like almost everyone concedes that silent deprecation is the way to go.  We still support string lambdas in the background, but in public docs we promote the use of the new lambda syntax. Would that be a fair assessment of this discussion?
> >
> >I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.
> 
> There's a related issue that I think we must solve before deciding whether or not we should deprecate string lambdas. Consider:
> 
> void main() {
>     import std.range;
>     SortedRange!(int[], "a > b") a;
>     SortedRange!(int[], "a > b") b;
>     b = a;
>     SortedRange!(int[], (a, b) => a > b) c;
>     SortedRange!(int[], (a, b) => a > b) d;
>     d = c;
> }
> 
> The last line fails to compile because D does not currently have a good notion of comparing lambdas for equality. In contrast, string comparison is well defined, and although string lambdas have clowny issues with e.g. "a>b" being different from "a > b", people have a good understanding of what to do to get code working.
> 
> So I think we should come up with a good definition of what comparing two function aliases means.
[...]

I'm not sure how the compiler handles delegates internally, but a first shot at it might be, any delegate with the same expression tree within the same scope should compare equally. I don't know if this is actually feasible to implement, though (I'm not familiar with DMD code).

The reason it must be the same scope is because otherwise, the delegate might be closing over different variables, so it should not be treated the same way (otherwise two delegates that are textwise the same may have different runtime behaviours, leading to a wrong conflation of template instantiations).


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On 8/11/13 11:46 AM, Walter Bright wrote:
> On 8/11/2013 9:26 AM, Andrei Alexandrescu wrote:
>> There's a related issue that I think we must solve before deciding
>> whether or
>> not we should deprecate string lambdas. Consider:
>>
>> void main() {
>>      import std.range;
>>      SortedRange!(int[], "a > b") a;
>>      SortedRange!(int[], "a > b") b;
>>      b = a;
>>      SortedRange!(int[], (a, b) => a > b) c;
>>      SortedRange!(int[], (a, b) => a > b) d;
>>      d = c;
>> }
>>
>> The last line fails to compile because D does not currently have a
>> good notion
>> of comparing lambdas for equality.
>
> Bugzilla?

http://d.puremagic.com/issues/show_bug.cgi?id=10819

Andrei

On Sunday, 11 August 2013 at 18:30:02 UTC, Tyler Jameson Little wrote:
> Correct me if I'm wrong, but AFAICT the old behavior was an undocumented feature. I couldn't find string lambdas formally documented anywhere, but lambdas are.

They are documented in std.functional: http://dlang.org/phobos/std_functional.html#.binaryFun

Namely because they are not a language feature but instead the power of D's other features.

> Comparing function aliases is an optimization, not a feature,

I don't really think it is an optimization either. What Andrei was requesting was a definition of what constitutes equality for equality for lambdas. However none of what I said should be taken to contradict your point that one can still use a named function to keep types equal.

> If the user needs the old behavior, he/she can do this today with an actual function

This assumes you are not receiving a sorted range from a third party library and passing it to another third party.