digitalmars.D - equality operators on types
- Timon Gehr (16/16) Jun 15 2012 Why not allow equality operators to operate on types?
- Dmitry Olshansky (11/27) Jun 15 2012 Now one day some n00b uses run-time if-chains to create type-switch
- Timon Gehr (8/33) Jun 15 2012 ...
- Dmitry Olshansky (6/41) Jun 15 2012 Except that type switch "usually" (if they could be counted as usual at
- bearophile (4/5) Jun 15 2012 That's nice, of course. But is it possible?
- Timon Gehr (2/5) Jun 15 2012 Yes, certainly.
- bearophile (5/13) Jun 15 2012 OK. Then do you know why the nice improvement you suggest was not
- Bernard Helyer (7/15) Jun 15 2012 Not without losing the context insensitivity of the D grammar
- Bernard Helyer (5/5) Jun 15 2012 Of course, "T == int" is unambiguous, but then when you can do
- Timon Gehr (2/6) Jun 16 2012 If done right, it makes parsing easier.
- Timon Gehr (13/31) Jun 16 2012 It is a comparison. That suffices for the parser. The grammar stays
- Bernard Helyer (8/35) Jun 16 2012 Sigh. If you're going to reply like that, it would be nice to
- Bernard Helyer (2/2) Jun 16 2012 Sorry, I'm being an asshole again. It's this newsgroup. It
- Timon Gehr (2/23) Jun 16 2012 FROM A PARSER LEVEL, NO!
- Jonathan M Davis (20/44) Jun 16 2012 It depends on the grammar. As it stands, with is(T == W), T and T must b...
- Bernard Helyer (7/37) Jun 16 2012 It absolutely would change the grammar (of the things I've
- Steven Schveighoffer (9/24) Jun 25 2012 Doesn't it already have to parse this today? I mean, is it the parser
- Timon Gehr (2/27) Jun 25 2012 You are right.
- Walter Bright (2/3) Jun 15 2012 Generally because of parsing problems.
- Timon Gehr (11/14) Jun 16 2012 What kind of problems? All types fit into the expression grammar well
- Walter Bright (3/10) Jun 16 2012 Perhaps it is possible if () are required, but one would have to careful...
- Timon Gehr (3/6) Jun 16 2012 By the way, 'is' expressions are not immune to parsing issues:
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
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
On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:On 15.06.2012 16:11, Timon Gehr wrote:... if(is(typeof(a) == Foo)) ... else if(is(typeof(a) == Bar)( ...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.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
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.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 OlshanskyThough "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
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
On 06/15/2012 02:19 PM, bearophile wrote:Timon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 15 2012
Timon Gehr:On 06/15/2012 02:19 PM, bearophile wrote:OK. Then do you know why the nice improvement you suggest was not the design used since the beginning instead of is(==)? Bye, bearophileTimon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 15 2012
On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:On 06/15/2012 02:19 PM, bearophile wrote: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.Timon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 15 2012
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
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. :PIf done right, it makes parsing easier.
Jun 16 2012
On 06/16/2012 07:19 AM, Bernard Helyer wrote:On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:It is a comparison. That suffices for the parser. The grammar stays completely context-independent.On 06/15/2012 02:19 PM, bearophile wrote:Not without losing the context insensitivity of the D grammar (because now we can't say for certain what "T == J" isTimon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?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
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:But we can't say whether T is a type or a value. _That_ matters.On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:It is a comparison. That suffices for the parser. The grammar stays completely context-independent.On 06/15/2012 02:19 PM, bearophile wrote:Not without losing the context insensitivity of the D grammar (because now we can't say for certain what "T == J" isTimon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?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.FROM A PARSER LEVEL, YES. >_<That's a big thing to throw away,T[2] foo; auto b = foo[1]; // is this legal?I don't think this argument is valid.Learn the difference between parsing valid and semantics, ffs.
Jun 16 2012
Sorry, I'm being an asshole again. It's this newsgroup. It does... strange things to me. Apologies.
Jun 16 2012
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:FROM A PARSER LEVEL, NO!On 06/16/2012 07:19 AM, Bernard Helyer wrote:But we can't say whether T is a type or a value. _That_ matters.On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:It is a comparison. That suffices for the parser. The grammar stays completely context-independent.On 06/15/2012 02:19 PM, bearophile wrote:Not without losing the context insensitivity of the D grammar (because now we can't say for certain what "T == J" isTimon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 16 2012
On Sunday, June 17, 2012 04:30:00 Timon Gehr wrote:On 06/17/2012 04:04 AM, Bernard Helyer wrote: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 DavisSigh. 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:FROM A PARSER LEVEL, NO!On 06/16/2012 07:19 AM, Bernard Helyer wrote:But we can't say whether T is a type or a value. _That_ matters.On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:It is a comparison. That suffices for the parser. The grammar stays completely context-independent.On 06/15/2012 02:19 PM, bearophile wrote:Not without losing the context insensitivity of the D grammar (because now we can't say for certain what "T == J" isTimon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 16 2012
On Sunday, 17 June 2012 at 02:30:00 UTC, Timon Gehr wrote:On 06/17/2012 04:04 AM, Bernard Helyer wrote: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.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:FROM A PARSER LEVEL, NO!On 06/16/2012 07:19 AM, Bernard Helyer wrote:But we can't say whether T is a type or a value. _That_ matters.On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:It is a comparison. That suffices for the parser. The grammar stays completely context-independent.On 06/15/2012 02:19 PM, bearophile wrote:Not without losing the context insensitivity of the D grammar (because now we can't say for certain what "T == J" isTimon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 16 2012
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: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 :) -SteveOn 06/15/2012 02:19 PM, bearophile wrote: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.Timon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 25 2012
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:You are right.On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote: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 :) -SteveOn 06/15/2012 02:19 PM, bearophile wrote: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.Timon Gehr:Yes, certainly.Why not allow equality operators to operate on types?That's nice, of course. But is it possible?
Jun 25 2012
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
On 06/16/2012 02:48 AM, Walter Bright wrote:On 6/15/2012 5:11 AM, Timon Gehr wrote: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.)Why not allow equality operators to operate on types?Generally because of parsing problems.
Jun 16 2012
On 6/16/2012 4:37 AM, Timon Gehr wrote:On 06/16/2012 02:48 AM, Walter Bright wrote:Perhaps it is possible if () are required, but one would have to carefully go through all the cases.On 6/15/2012 5:11 AM, Timon Gehr wrote:What kind of problems? All types fit into the expression grammar well enough. (pointer types should require parentheses in order to simplify parsing)Why not allow equality operators to operate on types?Generally because of parsing problems.
Jun 16 2012
On 06/16/2012 02:48 AM, Walter Bright wrote:On 6/15/2012 5:11 AM, Timon Gehr wrote:By the way, 'is' expressions are not immune to parsing issues: http://d.puremagic.com/issues/show_bug.cgi?id=6589Why not allow equality operators to operate on types?Generally because of parsing problems.
Jun 16 2012