I propose to adopt Olaf's suggestion here. It makes for a nice simple specification, even though *in principle* data T = MkT deriving( Eq ) needn't have a strict (==) operation. It's certainly a vagueness at the moment. Simon -----Original Message----- From: Olaf Chitil [mailto:olaf@cs.york.ac.uk] Sent: 08 February 2002 18:50 To: Simon Peyton-Jones Subject: Haskell 98 report In D.1 Derived instances of Eq and Ord. there is the statement Derived comparisons always traverse constructors from left to right. These examples illustrate this property: (1,undefined) == (2,undefined) => False (undefined,1) == (undefined,2) => _|_ This statement makes me wonder, if for example False <= undefined should evaluate to True, because False is the least constructor. However, all Haskell implementations yield "undefined". To resolve this ambiguity of the report I suggest to add the sentence: However, all derived comparisons are strict in all arguments. -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767
Simon Peyton-Jones writes: | I propose to adopt Olaf's suggestion here. : | -----Original Message----- | From: Olaf Chitil [mailto:olaf@cs.york.ac.uk] : | To resolve this ambiguity of the report I suggest to add the sentence: | However, all derived comparisons are strict in all arguments. How about these adjustments to the wording? "comparisons" -> "Eq and Ord class methods", to cover min and max, which are slightly more than just comparisons "all arguments" -> "both arguments", because I initially misunderstood it as "all arguments of both constructors" and started fretting that it would break existing programs Regards, Tom
participants (2)
-
Simon Peyton-Jones -
Tom Pledger