equality operators on types (page 2)

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.

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.)

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.

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.

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.

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!

June 17, 2012

Re: equality operators on types

Posted by Jonathan M Davis
in reply to Timon Gehr

Permalink

Jonathan M Davis

Posted in reply to Timon Gehr

Permalink

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

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.

Forums