Given the following code:

int[] arr = [1, 2, 9, 4, 10, 6];
auto r    = sort(arr);

if(is(typeof(r) == SortedRange!(int[], "a<b")))
writeln("first if");
 12
 13     if(is(typeof(r) == SortedRange!(int[], "a < b")))
 14         writeln("second if");

Sorry, I accidentally posted the above message and I don't know how to erase it.
The following post is the complete one:

Given the following code:

int[] arr = [1, 2, 9, 4, 10, 6];
auto r    = sort(arr);

if(is(typeof(r) == SortedRange!(int[], "a<b")))
    writeln("first if");

if(is(typeof(r) == SortedRange!(int[], "a < b")))
    writeln("second if");

The program outputs only "second if". I assumed that it should have printed both
ifs. Is this a bug?

Best regards,
RazvanN

On Tuesday, 8 November 2016 at 13:22:35 UTC, RazvanN wrote:
> Sorry, I accidentally posted the above message and I don't know how to erase it.

You can't, this is a mailing list not a forum.

> The following post is the complete one:
>
> Given the following code:
>
> int[] arr = [1, 2, 9, 4, 10, 6];
> auto r    = sort(arr);
>
> if(is(typeof(r) == SortedRange!(int[], "a<b")))
>     writeln("first if");
>
> if(is(typeof(r) == SortedRange!(int[], "a < b")))
>     writeln("second if");
>
> The program outputs only "second if". I assumed that it should have printed both
> ifs. Is this a bug?
>

equality of lambdas are fickle. String lambdas are comparable, because strings are comparable. Comparison of `(args){...body...}`  or `() => expression` lambdas don't work at all in template expressions.

`SortedRange!(int[], "a<b") == SortedRange!(int[], "a < b")` is false because the arguments to the templates differ i.e. "a<b" != "a < b".

Is this a bug? no. is it weird, confusing and unintuitive? yes.

On Tuesday, 8 November 2016 at 13:59:19 UTC, Nicholas Wilson wrote:
> You can't, this is a mailing list not a forum.

 > forum.dlang.org

On Tuesday, 8 November 2016 at 13:59:19 UTC, Nicholas Wilson wrote:
> On Tuesday, 8 November 2016 at 13:22:35 UTC, RazvanN wrote:
>> Sorry, I accidentally posted the above message and I don't know how to erase it.
>
> You can't, this is a mailing list not a forum.
>
>> The following post is the complete one:
>>
>> Given the following code:
>>
>> int[] arr = [1, 2, 9, 4, 10, 6];
>> auto r    = sort(arr);
>>
>> if(is(typeof(r) == SortedRange!(int[], "a<b")))
>>     writeln("first if");
>>
>> if(is(typeof(r) == SortedRange!(int[], "a < b")))
>>     writeln("second if");
>>
>> The program outputs only "second if". I assumed that it should have printed both
>> ifs. Is this a bug?
>>
>
> equality of lambdas are fickle. String lambdas are comparable, because strings are comparable. Comparison of `(args){...body...}`  or `() => expression` lambdas don't work at all in template expressions.
>
> `SortedRange!(int[], "a<b") == SortedRange!(int[], "a < b")` is false because the arguments to the templates differ i.e. "a<b" != "a < b".
>
> Is this a bug? no. is it weird, confusing and unintuitive? yes.

I think that lambda comparison should be done logically (by that I mean: what the function actually computes) not literally. For example: it is a mistake to consider the 2 two lambda functions different just because one expression has more white spaces. Also "a < b" is the same lambda function as "e < d"; considering these 2 functions to not be equal is a mistake.

On 11/08/2016 07:06 AM, RazvanN wrote:

>> `SortedRange!(int[], "a<b") == SortedRange!(int[], "a < b")` is false
>> because the arguments to the templates differ i.e. "a<b" != "a < b".
>>
>> Is this a bug? no. is it weird, confusing and unintuitive? yes.
>
> I think that lambda comparison should be done logically (by that I mean:
> what the function actually computes) not literally.

Still, from the point of view of the language string template parameters are not necessarily lambdas. The fact that a particular template may mix them in and use in similar fashion cannot change it.

> For example: it is a
> mistake to consider the 2 two lambda functions different just because
> one expression has more white spaces.

Possibly but again, the language not necessarily knows what that string means. The whitespace my be significant.

> Also "a < b" is the same lambda
> function as "e < d"; considering these 2 functions to not be equal is a
> mistake.

So-called "string lambdas" are actually pretty weird. You know that "e < d" cannot work with SortedRange, right? The string is actually mixed-in; so you have to know what the surrounding code expects and provide a matching string. In this case, you have to provide 'a' and 'b'.

Ali

On Tuesday, November 08, 2016 13:22:35 RazvanN via Digitalmars-d-learn wrote:
> Sorry, I accidentally posted the above message and I don't know
> how to erase it.
> The following post is the complete one:
>
> Given the following code:
>
> int[] arr = [1, 2, 9, 4, 10, 6];
> auto r    = sort(arr);
>
> if(is(typeof(r) == SortedRange!(int[], "a<b")))
>      writeln("first if");
>
> if(is(typeof(r) == SortedRange!(int[], "a < b")))
>      writeln("second if");
>
> The program outputs only "second if". I assumed that it should
> have printed both
> ifs. Is this a bug?

No, as the others have point out, it's not a bug. If anything it's a language design flaw that no one has figured out how to resolve yet.

The big thing here is that lambdas in general are not comparable, even if they are _exactly_ the same. e.g. this will fail to compile

int[] arr;
auto r1 = sort!((a, b) => a < b)(arr);
auto r2 = sort!((a, b) => a < b)(arr);
static assert(typeof(r1) == typeof(r2));

You get an error like

Error: static assert  (is(SortedRange!(int[], __lambda1) == SortedRange!
(int[], __lambda2))) is false

It doesn't think that __lambda1 and __lambda2 are the same, and that's with
two totally identical lambdas. The language and the compiler simply
do not have a way to do a comparison of lambdas. It's probably possible to
make them do it, but no one has figured out how to do it yet.

String lambdas predate the lambda syntax that I used above, and they have largely been replaced by that new syntax. But string lambdas are still in use in part because it's possible to compare strings for equality, and therefore it's possible to compare string lambdas for equality. But even then, it's comparing strings for exact equality and not attempting to decipher the strings. Part of that is because string lambdas are actually using a library construct - std.functional.binaryFun in this case - in order to work, so the language is just comparing two instances of the same instantiation of a template for equality - e.g. binaryFun!"a < b" and binaryFun!"a < b", which would be equal, or binaryFun!"a < b" and binaryFun!"a<b", which would not be. But even if string lambdas were built into the language as opposed to just being part of the standard library, we'd just be back to the problem that we have with comparing lambdas in general.

We'd very much like to see a solution to this problem implemented, but for now at least, it's just one of those annoyances that you have to deal with. And if you want two template instantiations with lambdas to be compatible, you either have to use string lambdas where the strings are identical, or you have to use an actual function rather than a lambda so that you can pass the same function to both template instantiations.

- Jonathan M Davis

On Tuesday, 8 November 2016 at 21:14:41 UTC, Jonathan M Davis wrote:
> No, as the others have point out, it's not a bug. If anything it's a language design flaw that no one has figured out how to resolve yet.

 The idea of a special struct for code that strips whitespace out, or a function that simply does the same thing... Either way it would have to be voluntary, preferably at the function level writing and not the user level.

 StringNWS? (No White Space) or StringCode?

 Might be something to try... Having a function to call that strips it would probably add too much overhead and ugliness required by users using the code vs code clarity.

 I'll have to experiment with this later.

On Tuesday, November 08, 2016 22:33:08 Era Scarecrow via Digitalmars-d-learn wrote:
> On Tuesday, 8 November 2016 at 21:14:41 UTC, Jonathan M Davis
>
> wrote:
> > No, as the others have point out, it's not a bug. If anything it's a language design flaw that no one has figured out how to resolve yet.
>
>   The idea of a special struct for code that strips whitespace
> out, or a function that simply does the same thing... Either way
> it would have to be voluntary, preferably at the function level
> writing and not the user level.
>
>   StringNWS? (No White Space) or StringCode?
>
>   Might be something to try... Having a function to call that
> strips it would probably add too much overhead and ugliness
> required by users using the code vs code clarity.
>
>   I'll have to experiment with this later.

The problem is that you can't strip out all whitespace. Some of it matters, and unless you do something like parse the code in the string, you can't know whether the whitespace matters or not. Ultimately, it's just easier to write your strings the same way, which usually is trivial.

- Jonathan M Davis