www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - equality operators on types

reply Timon Gehr <timon.gehr gmx.ch> writes:
Why not allow equality operators to operate on types?

is(==) expressions tend to create bracket noise and treat the two
arguments non-uniformly.

This would suggest a little parser update, so that eg. 'int', '(int*)'
and 'int[]' are accepted as valid expressions. (this also potentially
improves compiler error messages.)

void foo(T)(T arg){
     static if(T==int){
         ...
     }else{
         ...
     }

     static if(T!=double) ...
}

As far as I can see, this would be fully backwards-compatible.
(modulo compile-time introspection.)
Jun 15 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 15.06.2012 16:11, Timon Gehr wrote:

 Why not allow equality operators to operate on types?

 is(==) expressions tend to create bracket noise and treat the two
 arguments non-uniformly.

 This would suggest a little parser update, so that eg. 'int', '(int*)'
 and 'int[]' are accepted as valid expressions. (this also potentially
 improves compiler error messages.)

 void foo(T)(T arg){
 static if(T==int){
 ...
 }else{
 ...
 }


Now one day some n00b uses run-time if-chains to create type-switch 
(that doesn't work because it would CT-defined):
...
if( typeof(a) == Foo)
...
else if(typeof(a) == Bar)
...

Though "code is unreachable" warning might help with it.

 static if(T!=double) ...
 }

 As far as I can see, this would be fully backwards-compatible.
 (modulo compile-time introspection.)



-- 
Dmitry Olshansky
Jun 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:

 On 15.06.2012 16:11, Timon Gehr wrote:

 Why not allow equality operators to operate on types?

 is(==) expressions tend to create bracket noise and treat the two
 arguments non-uniformly.

 This would suggest a little parser update, so that eg. 'int', '(int*)'
 and 'int[]' are accepted as valid expressions. (this also potentially
 improves compiler error messages.)

 void foo(T)(T arg){
 static if(T==int){
 ...
 }else{
 ...
 }


 Now one day some n00b uses run-time if-chains to create type-switch
 (that doesn't work because it would CT-defined):
 ...
 if( typeof(a) == Foo)
 ...
 else if(typeof(a) == Bar)
 ...


...
if(is(typeof(a) == Foo))
...
else if(is(typeof(a) == Bar)(
...


 Though "code is unreachable" warning might help with it.


Or any of the other compile time errors that is generated in the
unreachable code because it cannot compile with the given parameters.
Jun 15 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 15.06.2012 16:56, Timon Gehr wrote:

 On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:

 On 15.06.2012 16:11, Timon Gehr wrote:

 Why not allow equality operators to operate on types?

 is(==) expressions tend to create bracket noise and treat the two
 arguments non-uniformly.

 This would suggest a little parser update, so that eg. 'int', '(int*)'
 and 'int[]' are accepted as valid expressions. (this also potentially
 improves compiler error messages.)

 void foo(T)(T arg){
 static if(T==int){
 ...
 }else{
 ...
 }


 Now one day some n00b uses run-time if-chains to create type-switch
 (that doesn't work because it would CT-defined):
 ...
 if( typeof(a) == Foo)
 ...
 else if(typeof(a) == Bar)
 ...





 ...
 if(is(typeof(a) == Foo))
 ...
 else if(is(typeof(a) == Bar)(
 ...


Well that looks unnatural, noobs would have a reason to suspect something.


 Though "code is unreachable" warning might help with it.


 Or any of the other compile time errors that is generated in the
 unreachable code because it cannot compile with the given parameters.


Except that type switch "usually" (if they could be counted as usual at 
all) followed by a cast to the said type. Think trash quality polymorphism.

-- 
Dmitry Olshansky
Jun 15 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:


 Why not allow equality operators to operate on types?


That's nice, of course. But is it possible?

Bye,
bearophile
Jun 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


Yes, certainly.
Jun 15 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:


 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


OK. Then do you know why the nice improvement you suggest was not 
the design used since the beginning instead of is(==)?

Bye,
bearophile
Jun 15 2012
prev sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


Not without losing the context insensitivity of the D grammar 
(because now we can't say for certain what "T == J" is until we 
semantically understand the program, but as it is now we 
understand it as comparing two values). That's a big thing to 
throw away, and this doesn't justify the change.

-Bernard.
Jun 15 2012
next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
Of course, "T == int" is unambiguous, but then when you can do 
that and not "T == J" you'll confuse people ("the compiler knows 
T and J are types...") and that rabbit hole is a dangerous one. 
Mainly because it makes parsing more difficult. I am nothing if 
not biased. :P
Jun 15 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 07:24 AM, Bernard Helyer wrote:

 Of course, "T == int" is unambiguous, but then when you can do that and
 not "T == J" you'll confuse people ("the compiler knows T and J are
 types...") and that rabbit hole is a dangerous one. Mainly because it
 makes parsing more difficult. I am nothing if not biased. :P


If done right, it makes parsing easier.
Jun 16 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 07:19 AM, Bernard Helyer wrote:

 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


 Not without losing the context insensitivity of the D grammar (because
 now we can't say for certain what "T == J" is


It is a comparison. That suffices for the parser. The grammar stays 
completely context-independent.


 until we semantically
 understand the program, but as it is now we understand it as comparing
 two values).


As it is now we don't know what it will do.

import some.other.module;
S a, b;
bool c = a == b;

///////
module some.other.module

struct S{ bool opEquals(){ hardDrive.format(); assert(0); } }



 That's a big thing to throw away,


T[2] foo;
auto b = foo[1]; // is this legal?


 and this doesn't justify the change.

 -Bernard.


I don't think this argument is valid.
Jun 16 2012
parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
Sigh. If you're going to reply like that, it would be nice to 
know you had the slightest fucking clue what you're talking about.

On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:

 On 06/16/2012 07:19 AM, Bernard Helyer wrote:

 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


 Not without losing the context insensitivity of the D grammar 
 (because
 now we can't say for certain what "T == J" is


 It is a comparison. That suffices for the parser. The grammar 
 stays completely context-independent.


But we can't say whether T is a type or a value. _That_ matters.


 import some.other.module;
 S a, b;
 bool c = a == b;


Again, from a parser level.


 ///////
 module some.other.module

 struct S{ bool opEquals(){ hardDrive.format(); assert(0); } }


FROM A PARSER LEVEL.




 That's a big thing to throw away,


 T[2] foo;
 auto b = foo[1]; // is this legal?


FROM A PARSER LEVEL, YES. >_<


 I don't think this argument is valid.


Learn the difference between parsing valid and semantics, ffs.
Jun 16 2012
next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
Sorry, I'm being an asshole again. It's this newsgroup. It 
does... strange things to me. Apologies.
Jun 16 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/17/2012 04:04 AM, Bernard Helyer wrote:

 Sigh. If you're going to reply like that, it would be nice to know you
 had the slightest fucking clue what you're talking about.

 On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:

 On 06/16/2012 07:19 AM, Bernard Helyer wrote:

 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


 Not without losing the context insensitivity of the D grammar (because
 now we can't say for certain what "T == J" is


 It is a comparison. That suffices for the parser. The grammar stays
 completely context-independent.


 But we can't say whether T is a type or a value. _That_ matters.


FROM A PARSER LEVEL, NO!
Jun 16 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 17, 2012 04:30:00 Timon Gehr wrote:

 On 06/17/2012 04:04 AM, Bernard Helyer wrote:

 Sigh. If you're going to reply like that, it would be nice to know you
 had the slightest fucking clue what you're talking about.
 
 On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:

 On 06/16/2012 07:19 AM, Bernard Helyer wrote:

 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:

 Why not allow equality operators to operate on types?


 
 That's nice, of course. But is it possible?


 
 Yes, certainly.


 
 Not without losing the context insensitivity of the D grammar (because
 now we can't say for certain what "T == J" is


 
 It is a comparison. That suffices for the parser. The grammar stays
 completely context-independent.


 
 But we can't say whether T is a type or a value. _That_ matters.


 
 FROM A PARSER LEVEL, NO!


It depends on the grammar. As it stands, with is(T == W), T and T must be 
types, and with T == W, they _cannot_ be types. If a different grammar rule 
were used inside of is, then you'd get a different result for what types of 
tokens the parser considers T and W to be. If you got rid of is(T == W) in 
favor of T == W, then the parser could no longer determine their types. That 
can certainly work - but only if the semantic analyzer is okay with the parser 
not knowing what T and W are.

As it stands, IsExpression is its own rule in the grammar, and it expects T == 
W to be Type == TypeSpecialization, so the grammar rules are _defnitely_ 
different when == is used in an is expression is used than when == is used 
outside of an is expression.

So, what you're suggesting would definitely mean changing the grammar, and it 
would mean giving the semantic analyzer less information from the parser 
(since it couldn't tell the semantic analyzer whether T and W were types or 
not). I expect that it's feasible, but it would be a large change. And one 
major downside would be that it would be impossible for a program which used 
the parser but not the semantic analyzer (e.g. for syntax highlighting) would 
then need the semantic analyzer as well to actually do what it does.

- Jonathan M Davis
Jun 16 2012
prev sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Sunday, 17 June 2012 at 02:30:00 UTC, Timon Gehr wrote:

 On 06/17/2012 04:04 AM, Bernard Helyer wrote:

 Sigh. If you're going to reply like that, it would be nice to 
 know you
 had the slightest fucking clue what you're talking about.

 On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:

 On 06/16/2012 07:19 AM, Bernard Helyer wrote:

 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


 Not without losing the context insensitivity of the D 
 grammar (because
 now we can't say for certain what "T == J" is


 It is a comparison. That suffices for the parser. The grammar 
 stays
 completely context-independent.


 But we can't say whether T is a type or a value. _That_ 
 matters.


 FROM A PARSER LEVEL, NO!


It absolutely would change the grammar (of the things I've 
written and the things I've studied). It may or may not change 
DMD's grammar, depending on whether it's over generalised -- I 
haven't looked.

It's clear that you think it's not a change of any import, but I 
do.
Jun 16 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 16 Jun 2012 01:19:49 -0400, Bernard Helyer <b.helyer gmail.com>  
wrote:


 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


 Not without losing the context insensitivity of the D grammar (because  
 now we can't say for certain what "T == J" is until we semantically  
 understand the program, but as it is now we understand it as comparing  
 two values). That's a big thing to throw away, and this doesn't justify  
 the change.


Doesn't it already have to parse this today?  I mean, is it the parser  
that decides T == J is invalid if T and J are types, or something later?

It doesn't seem to me to be an issue with context insensitivity, if you  
have no context, you *already* can't know whether "T == J" is valid or  
not.  By itself, T == J fits into D's grammar.

Bitch-slap me if I'm wrong, I'm certainly not an expert in this here :)

-Steve
Jun 25 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 02:40 PM, Steven Schveighoffer wrote:

 On Sat, 16 Jun 2012 01:19:49 -0400, Bernard Helyer <b.helyer gmail.com>
 wrote:


 On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:

 On 06/15/2012 02:19 PM, bearophile wrote:

 Timon Gehr:


 Why not allow equality operators to operate on types?


 That's nice, of course. But is it possible?


 Yes, certainly.


 Not without losing the context insensitivity of the D grammar (because
 now we can't say for certain what "T == J" is until we semantically
 understand the program, but as it is now we understand it as comparing
 two values). That's a big thing to throw away, and this doesn't
 justify the change.


 Doesn't it already have to parse this today? I mean, is it the parser
 that decides T == J is invalid if T and J are types, or something later?

 It doesn't seem to me to be an issue with context insensitivity, if you
 have no context, you *already* can't know whether "T == J" is valid or
 not. By itself, T == J fits into D's grammar.

 Bitch-slap me if I'm wrong, I'm certainly not an expert in this here :)

 -Steve


You are right.
Jun 25 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2012 5:11 AM, Timon Gehr wrote:

 Why not allow equality operators to operate on types?


Generally because of parsing problems.
Jun 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 02:48 AM, Walter Bright wrote:

 On 6/15/2012 5:11 AM, Timon Gehr wrote:

 Why not allow equality operators to operate on types?


 Generally because of parsing problems.


What kind of problems? All types fit into the expression grammar well 
enough. (pointer types should require parentheses in order to simplify 
parsing)

The parser can already parse this:

static if(int.min == (int*).min) { }

It should be trivial to adapt it so that it can parse this:

static if(int == (int*)) { }

(in essence, stop requiring the scope resolution after everything that 
unambiguously looks like a type. The current behaviour is inconsistent
anyway.)
Jun 16 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2012 4:37 AM, Timon Gehr wrote:

 On 06/16/2012 02:48 AM, Walter Bright wrote:

 On 6/15/2012 5:11 AM, Timon Gehr wrote:

 Why not allow equality operators to operate on types?


 Generally because of parsing problems.


 What kind of problems? All types fit into the expression grammar well enough.
 (pointer types should require parentheses in order to simplify parsing)


Perhaps it is possible if () are required, but one would have to carefully go 
through all the cases.
Jun 16 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 02:48 AM, Walter Bright wrote:

 On 6/15/2012 5:11 AM, Timon Gehr wrote:

 Why not allow equality operators to operate on types?


 Generally because of parsing problems.


By the way, 'is' expressions are not immune to parsing issues:
http://d.puremagic.com/issues/show_bug.cgi?id=6589
Jun 16 2012