things to throw away?

[Claus Reinke]

>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'.