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