Due to a lack of administrative competance on my part, these two messages went to the
individuals but not to the discussion list. Thanks to Paola for sorting things out.
I am putting both replies together so the email got a bit long.
The first email was a reply to Bjorn Reese
> I disagree that there is a problem.
>
> > The point that was being raised was that the reversal results in a conceptual
> > problem, because we tend to read the source code left-to-right, just like we
> > read English. For example, if our variable is called 'colour' and our constant
> > 'blue', then
> >
> > if (colour == blue)
> >
> > is read as "if the colour is blue", but the following
> >
> > if (blue == colour)
> >
> > can be read as "if blue is a colour" (which would always be true, regardless
> > of the value of the colour variable), even though the compiler interprets it
> > as "if colour is blue".
>
> Equality (unlike assignment) is commutative so:
>
> x == y
>
> and
>
> y == x
>
> are the same expression; because the operator is commutative the ordering must
> always be reversible without changing the semantics (the definition of commutative
> in this case). Thus your second interpretation is not reasonable. Also, in the
> earlier examples colour was a variable but in the last example colour must be a
> type name for the interpretation to be sensible. These are completely different
> things in C/C++/Java and so the compiler would almost certainly be upset if the
> concepts were mixed.
>
> The question "if blue is a colour" involves the type hierarchy and hence intimately
> involves language specific and application specific structures. Assuming that blue
> is a constant and colour is a variable, then is C it is most likely that the
> following would be used:
>
> typedef enum Colour { red, green, blue } Colour ;
>
> would be the way of defining the type and the constant. This leads to the
> tautology "blue is a Colour". If we then had:
>
> Colour colour = red ;
>
> affirming that colour is a variable, then:
>
> if ( blue == colour )
>
> cannot be read as "if blue is a colour", this is a non-sensible interpretation. In
> C++ we would have the simpler:
>
> enum Colour { red, green, blue } ;
>
> but the rest would be the same. In C++, we can however ask the question:
>
> if (typeid(blue) == typeid(Colour))
>
> or
>
> if (typeid(blue) == typeid(colour))
>
> or
>
> if (typeid(colour) == typeid(Colour))
>
> which is the nearest thing to the question you want. (But I note that such code
> almost certainly means lack of language understanding by the programmer or (more
> likely) a bad design of program on the part of the program designer.)
>
> Java is slightly (!) messy on this since there are no enumerated types as in
> C/C++. Instead the ancient C technique of explicit representation (yuk) must be
> used:
>
> class Colour {
> public static Colour red = 1 ;
> public static Colour green = 2 ;
> public static Colour blue = 3 ;
> ...
> }
>
> Again blue is a Colour by definition but the question of type equality can still be
> asked:
>
> if (blue instanceof Colour)
>
> So the interpretation you give is a valid question to ask but is not a valid
> interpretation of the equality operator.
>
> Please forgive my bluntness here but any C/C++/Java programmer who interpreted:
>
> if (blue == colour)
>
> as "if blue is a colour" if colour is a variable and not a type name is clearly a
> beginner who needs to learn much more about the language.
>
> The moral of the story is that we need to separate errors made by people learning a
> language from errors made by those who should know what the semantics are. This
> =/== problem is a very serious problem but interpretations of the problem must be
> from the right sub-domain.
The other message was a reply to Arthur van Leeuwen's email:
> > In the case of assignments in if statements there's a powerful idiom,
> > and that is if((file=fopen(file))==NULL) { handle_open_error(); }
> > This makes for the least visual distraction from the main flow of the
> > code, and is therefore very accepted practice.
>
> The issue here is that the outermost expression is a Boolean expression. I believe
> that coding style should always require an explicit Boolean expression. So:
>
> if (x = y)
>
> should never be allowed, either it is:
>
> if (x == y)
>
> or
>
> if ((x = y) != 0)
>
> Your example fits exactly this model which is, as you point out, a classic idiom of
> use. Derek Jones pointed out the fact that optimizing compilers can now do an
> excellent job of redundant code elimination and hence the programmer can go for
> expressivity as much as optimization. Personally I am not worried by his concern
> regarding compilers that cannot do a proper job of optimizing, I just refuse to
> allow the use of any compiler that cannot do a proper optimization job. Survival
> of the fittest (which means most functional not most popular or most frequent) gets
> rid of incapable compilers.
Russel.
======================================================================
Professor Russel Winder Professor of Computing Science
Department of Computer Science Fax: +44 20 7848 2851/+44 20 7848 2913
King's College London [EMAIL PROTECTED]
Strand, London WC2R 2LS, UK http://www.dcs.kcl.ac.uk/staff/russel/
- Automatic footer for [EMAIL PROTECTED] ----------------------------------
To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss
To join the announcements list, mail [EMAIL PROTECTED] subscribe announce
To receive a help file, mail [EMAIL PROTECTED] help
This list is archived at http://www.mail-archive.com/discuss%40ppig.org/
If you have any problems or questions, please mail [EMAIL PROTECTED]
