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'.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
