www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - typeof(SortedRange) and is operator

reply RazvanN <razvan.nitu1305 gmail.com> writes:
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");
Nov 08 2016
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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
Nov 08 2016
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Nov 08 2016
next sibling parent WebFreak001 <janju007 web.de> writes:
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
Nov 08 2016
prev sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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.
Nov 08 2016
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Nov 08 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Nov 08 2016
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
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.
Nov 08 2016
parent Jonathan M Davis via Digitalmars-d-learn writes:
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
Nov 08 2016