Re: Haskell 98: Enum Class
George Russell [EMAIL PROTECTED] writes: In addition, I suggest that, since it is widely agreed that the instances of Enum for Float and Double And (Ratio a)? are highly unsatisfactory -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98: Enum Class
Ketil Malde wrote: George Russell [EMAIL PROTECTED] writes: In addition, I suggest that, since it is widely agreed that the instances of Enum for Float and Double And (Ratio a)? Yes, you've got a point there. They'd none of 'em be missed. Of course mathematicians are well aware that rational numbers can be enumerated, just not the way the Haskell standard does it . . . ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell 98: Enum Class
| In addition, I suggest that, since it is widely agreed that | the instances of Enum for Float and Double are highly | unsatisfactory, the report should give these instances the | same status as n+k patterns have (in 1.4 of the recent | revision). In particular, their use should be discouraged, | and there | should be a warning that the instances may be altered or | removed in Haskell 2. | | It might clear the ground somewhat for Haskell 2 if there | were a new section containing a list of deprecated features; | we can probably think of some other things which should go in | there. In addition to what's said for n+k patterns, I | suggest the standard explicitly encourage (but not oblige) | conforming compilers to issue warnings when deprecated | features are used. The Revised Haskell 98 report is suppposed to be in conclusion mode. An attempt to decide what features are deprecated would open up a big new debate. One could instead list features which are controversial --- that would be easier. Whether it would actually be worth the work of getting consensus on such a list is not clear to me. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell 98: Enum class
| Somebody raised the issue why to/fromEnum doesn't use Integer | instead of Int. This would, it would seem, solve at least | some of the Enum problems that arise from (integral) types | with more than 4G values. So, again, why not? There was an extended discussion on this point, I believe, during the Haskell 1.4 -- Haskell 98 transition. I forget the details, but I expect that efficiency was an issue. However, regardless of the merits of the case, changing the type of to/fromEnum is not a possibility for the Haskell 98 report, I'm afraid. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98: Enum Class
Simon Peyton-Jones wrote: [snip] The Revised Haskell 98 report is suppposed to be in conclusion mode. An attempt to decide what features are deprecated would open up a big new debate. One could instead list features which are controversial --- that would be easier. Whether it would actually be worth the work of getting consensus on such a list is not clear to me. I don't really understand what is meant by controversial. For n+k patterns we can summarise section 1.4 as saying (1) they are discouraged. (2) they may be altered or removed in a future version of Haskell. (3) implementors are encouraged to provide a mechanism for users to selectively enable or disable them. (Personally I would prefer warnings, but the difference isn't very important; in both cases the effect is to draw the users' attention to the use of deprecated features.) Now I think that, at least, the use of the instance of Enum Float/Double should also be like this. Does anyone actually disagree with this? Fortunately I am not responsible for revising the Haskell standard. I say fortunately, because there a very large number of things I would change if redesigning the language from scratch, and I might be tempted to try and sneak them into the current revision. In the current circumstances, I think the best we can do is try to identify those features which can safely be deprecated without upsetting a large body of users. n+k patterns are safely in there, and I think Enum Float/Double should be too. I think the suggestion that contexts in datatypes should also be on the list is a good one, since at the moment they do nothing useful, though a future change might more sensibly change them so that they do. I appreciate the problem if the Haskell98 revision has to be completed in the very near future. Is there a set timetable? I think we should be able to reach some conclusion on an agreed set of deprecated features in the next month at the worst. I wonder if we should make some kind of shared intensive effort to track down some of the remaining bugs in the Haskell standard. It's a bit unfair putting it all on SPJ's shoulders. I've already had a go at being pedantic with the lexing and layout sections. I don't mind doing the same with another few pages of the library or report, if some other people will do so too so we can debug the whole thing. Then perhaps we might be able to get the whole thing done by Christmas. George Russell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98: Enum class
On Wed, Oct 24, 2001 at 07:51:12AM -0700, Simon Peyton-Jones wrote: The Report is (regrettably) silent about what the Integer instances for succ and pred should be, but they should definitely simply add 1 (resp subtract 1). They should emphatically not use the default methods. I will add something to that effect in 6.3.4. ... 3. Specify that succ and pred on numeric types just add/subtract 1 (subject to (2) above). Can you write some code people can cutpaste for instance of Enum on ordered numeric types, just so this is crystal clear? You might even put in some bounds checking: succ x = let y = x+1 in if y x then y else error succ overflowed --Dylan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98: Enum class
| | (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's | | specification here: succ = toEnum . (+1) . fromEnum | | This is confirmed by the description of the semantics in | | section 3.10.) | | Lies, all lies. The default methods do not constitute a specification; | in this case at least, they only approximate the truth. But the Report is emphatic that Appendix A _does_ constitute a specification for the Prelude, and I had always assumed that the default definitions given there are safe for all types, though not necessarily efficient. If the default methods are semantically incorrect (for some types) then they must be changed or removed. | The Report is (regrettably) silent about what the Integer | instances for succ and pred should be, but they should definitely simply | add 1 (resp subtract 1). Admittedly section 3.10 does not mention succ and pred explicitly, but it does otherwise confirm the semantics of the current default definitions, namely that: For other discrete Prelude types t that are instances of Enum, namely ... Integer, the semantics is given by mapping ... to Int using fromEnum, ... , and then mapping back to t with toEnum. However I agree that succ = (+1) pred = (\x- x-1) would make better sense. 5. In Appendix A, the Enum class defn, add comments to explain that the default methods only work for types whose fromEnum/toEnum range fits inside Int. I would rather have correct default definitions. Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
