We must find *something* to throw away though! :-) Simon
Indeed. One of the things I had been hoping for in Haskell' was the removal of the many conservative restrictions put into earlier definitions: they complicate the language definition, restrict expressiveness, and have prompted various extensions. - mr - the whole bunch of "you can't do this (we think)" in type classes and their instances, when nowadays we know that type class instances are all about logical meta-programming at the type level. non-decidability should still be optional, but also, at least standardised. - .. (btw, I hope I'm not misquoting, but I think it was Mark Jones who said that permitting complex type parameters was more important than having multiple parameters in type classes - you can simulate multiple parameters by tupling) anyway. Just as I was disturbed by the many not-yet-existing features under discussion, I am worried about the new trend of proposing not to include old friends (MPTC, concurrency, functional dependencies, ..). If that should happen, Haskell' will be just as irrelevant as Haskell98 was, before the FFI addendum (how many Haskell98 programs were there that did not use "primitives"?). So I repeat my opinion: the committee should not limit itself to a single, all-encompassing standard. There are things that can and need to be standardised, for which we do not yet know whether they should be frozen into _the_ standard forever, and there are things that need to be standardized, for which the standardization might take too long to match the Haskell' timeline. The established answer to such changeability in software is to modularize, and the same should happen for the language standard. I agree with Patryk here (I even like the idea of abusing imports to specify language extensions in use, though I would simply use a combination of imports and reserved parts of the module hierarchy, without modifying the import syntax at all). Perhaps we cannot have Concurrent Haskell in all Haskell' implementations, or perhaps Functional Dependencies will be replaced by something else in the future. But when I use either of them, I want to be able to write code that any supporting Haskell'+CH+FD implementation will understand and interpret the same way, and about which any non-supporting Haskell' implementation will be able to tell me exactly what it is that it doesn't support (instead of giving obscure syntax errors). Scanning over the import lines and reporting that "no, sorry, we don't have Language.Haskell. Extensions.Types.FancyRankN here" should do the latter quite nicely, and allows to document the former in the same way as libraries. Cheers, Claus PS Someone suggested searching the libraries for features that are in use and should therefore be included in Haskell'. Another thing to look for are preprocessor directives protecting differences between implementations. Also, perhaps someone could write a simple program analyzer that people could run over their own code repositories to report features in use back here (perhaps based on the extended Haskell syntax parser)? You'll need something like this anyway, as part of moving code from Haskell98 and Haskell(GHC), ... to Haskell'.