Haskell 98: Enum Class
Thu, 25 Oct 2001 15:57:52 +0200
Simon Peyton-Jones wrote:
> 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