Folks, I'm about to put out (what I hope is) the final revised Haskell98 report. Here, though, is one good point I propose to clarify. I propose to say that every H98 impl must support tuples up to size 7 and their instances for Eq, Ord, Bounded, Read, Show [Of course, one might hope that impls would do better, but the report should be conservative.] Simon | -----Original Message----- | From: Olaf Chitil [mailto:olaf@cs.york.ac.uk] | Sent: 23 April 2001 12:11 | To: nhc-users@cs.york.ac.uk | Cc: haskell@haskell.org; Simon Peyton-Jones | Subject: Re: Eq instance for (a,b,c,d,e) and upwards | | | | I think that this discussion about tuples shows that there is | a problem with the Haskell 98 report which should be | corrected. I hope Simon accepts it as a minor bug fix. | | 1) The current wording of paragraph 6.1.4 is highly ambigious. | | > 6.1.4 Tuples | > | > Tuples are algebraic datatypes with special syntax, as defined | > in Section 3.8. Each tuple type has a single constructor. There | > is no upper bound on the size of a tuple. However, some Haskell | > implementations may restrict the size of tuples and limit the | > instances associated with larger tuples. The Prelude and | libraries | > define tuple functions such as zip for tuples up to a | size of 7. All | > tuples are instances of Eq, Ord, Bounded, Read, and Show. Classes | > defined in the libraries may also supply instances for | tuple types. | | May the limit for the size of tuples and the limit for | instances be different? Do tuples exist at least for a size | up to 7? What is the purpose of the last sentence? | | We should decide what we want and the paragraph should then | state it clearly. | | 2) The arbitrary restrictions that Haskell implementations | are permitted to apply, basically imply that you shouldn't | use tuples at all if you want your code to be portable. Maybe | there isn't even a Show instance for ()? | | So I think the report should demand that tuples and instances | for Eq,Ord,Bounded,Read and Show should be implemented for at | least up to a size of a given number n. | | 3) I propose this number n to be 7. This fits well with the | fact that zip etc are defined for tuples up to a size of 7. I | agree with Martin that you should use a labelled record or at | least an own type instead of large tuples anyway. | Programs that generate code should als generate definitions | for data types, if large product types are needed. | | Olaf | | -- | OLAF CHITIL, | Dept. of Computer Science, University of York, York YO10 5DD, UK. | URL: http://www.cs.york.ac.uk/~olaf/ | Tel: +44 1904 434756; Fax: +44 1904 432767 |
Hi, Simon Peyton-Jones wrote:
Folks,
I'm about to put out (what I hope is) the final revised Haskell98 report.
Here, though, is one good point I propose to clarify. I propose to say that
every H98 impl must support tuples up to size 7 and their instances for Eq, Ord, Bounded, Read, Show
[Of course, one might hope that impls would do better, but the report should be conservative.]
Clearly, the report has to state the minimal bound. And I agree that 7 is a choice which is consistent with the current Prelude. However, 7 is also a number which is uncomfortably close to what I've seen in real code and used myself. Yes, one might hope that this is a non issue, since all implementations I'm aware of does considerably better anyway. But if one wants to write portable code, it does become an issue. And yes, one could argue that records or user-defined product types should be used anyway. But that is really a matter of taste, and I'd say that there are reasonable examples where forcing the user to introduce a product type just to wrap up a bunch of values would harm rather than improve the readability. So, if, in the interest of being conservative, the stated minimal bound cannot be "infinity", could it at least be a great deal bigger than what reasonably would be used in *hand-written* code? Say 15. An arbitrary choice, of course, but it is not excessive from an implementation perspective, yet large enough that I cannot imagine hand-written code getting close to the limit. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
Henrik Nilsson wrote:
So, if, in the interest of being conservative, the stated minimal bound cannot be "infinity", could it at least be a great deal bigger than what reasonably would be used in *hand-written* code? Say 15. An arbitrary choice, of course, but it is not excessive from an implementation perspective, yet large enough that I cannot imagine hand-written code getting close to the limit.
I second Henrik here, 15 is much better than 7. Cheers, Ralf
Ralf Hinze <ralf@informatik.uni-bonn.de> wrote,
Henrik Nilsson wrote:
So, if, in the interest of being conservative, the stated minimal bound cannot be "infinity", could it at least be a great deal bigger than what reasonably would be used in *hand-written* code? Say 15. An arbitrary choice, of course, but it is not excessive from an implementation perspective, yet large enough that I cannot imagine hand-written code getting close to the limit.
I second Henrik here, 15 is much better than 7.
I agree. Manuel
participants (4)
-
Henrik Nilsson -
Manuel M. T. Chakravarty -
Ralf Hinze -
Simon Peyton-Jones