welcome to the discussion!-)
(A) It's not as if every interesting program (or even the majority of
interesting programs) use(s) MPTCs.
well, I express my opinions and experience, and you express your's:-)
let's hope that Haskell' will accomodate both of us, and all the other
possible views and applications of Haskellers in general, to the extent
that they are represented here.
(B) I don't think the time for which an extension has been around is
particularly relevant.
oh yes, it is. don't get me wrong, we have ample proof that having
been around for long does not imply good, necessary or even just
well-understood. but it is certainly relevant, as it demonstrates
continued use.
haskell prime is an attempt to standardize current Haskell practice,
and MPTCs and FDs have been part of that for a long time, so haskell
prime has to take a stand about them. Haskell98 could get away with
closed eyes, claiming that those features were new then, just as GADTs
and ATS are new today. haskell prime does not have that choice
any more.
so I see two choices:
- define current practice in MPTCs and FDs, then mark those then
well-defined extensions as deprecated, to be removed in Haskell''.
to do this, you'd need to provide a clear alternative to migrate to,
with a simple and complete definition both of the feature set you
are advocating, and its interactions with other features, and its
relation to the features it is meant to replace.
- define current practice in MPTCs and FDs, find the simple story
behind these features and their interactions with other features
(as simple as we can make it, without the scaremongering), and
add that to Haskell'.
also define the initial versions of your alternative feature sets
and their interactions. leave it to Haskell'' to decide which of
the two to deprecate, if any.
either option needs a definition of both feature sets (I assume you're
arguing for associated type synonyms). we do have fairly simple
definitions of MPTCs and FDs, although I still think (and have been
trying to demonstrate) that the restrictions are too conservative.
what we don't have are definitions of the interactions with other
features (and the restrictions really get in the way here), such as
overlap resolution, or termination proofs, but we are making
progress there. what we also don't have is a simple definition
of ATS, its interactions with other features, and a comparison
of well-understood ATS with well-understood FDs (I only just
printed the associated FD paper, perhaps that'll help), which
could form the basis for a decision between the two.
so, imho, haskell prime can only define the current state, hopefully
with a better form of MPTCs/FDs and at least some preliminary
form of ATS, and let practice over the next years decide whether
haskellers will move from MPTCs/FDs to ATS. just as practice
seems to have decided that other features, eg, implicit parameters,
in spite of their initial popularity, have not recommended themselves
for any but the most careful and sparing use, and not as part of
the standard.
One of the big selling points of Haskell is that
it's quite well defined, and hence, its semantics is fairly well
understood and sane - sure, there are dark corners, but compared to
other languages of the same size, we are in good shape. If we include
half-baked features, we weaken the standard.
we are not in a good shape. Haskell 98 doesn't even have a semantics.
current Haskell is so full of dark corners, odd restrictions and unexpected
feature interactions that I've been tempted to refer to it as the C++ of
functional languages. the question on the table is not wether to include
half-baked features of current Haskell in Haskell', but how to make sure
that we understand those features well enough to make an informed
decision. nothing I've seen so far indicates that it is impossible to come
up with a well-defined form of some of those features, including their
interactions with other features. that doesn't come without some
further work, so the haskell prime effort cannot just pick and choose,
but there's no reason to give up just yet.
and to keep what is good about Haskell, we need to think about
simplifying the features we have as our understanding of them improves,
in particular, we need to get rid of unnecessary restrictions (they
complicate the language), and we need to investigate feature interactions.
we weaken the standard if it has nothing to say about the problems
in current practice.
In fact, it's quite worrying that FDs have been around for so long and
still resisted a thorough understanding.
they don't resist. but as long as progress is example-driven and scary
stories about FDs supposedly being tricky and inherently non-under-
standable are more popular than investigations of the issues, there
won't be much progress. please don't contribute to that hype.
you reply to a message that is about a month old. since then, every
single example of FD "trickyness" presented here has been resolved
(or have we missed some example?), and as far as I'm concerned,
the remaining problems are due to feature interactions, and need a
more systematic approach. personally, I'm looking into interactions
with overlap resolution, trying to narrow down feature use cases
and define their interactions with FDs and FD restrictions.
it is okay to advertize for your favourite features. in fact, I might
agree with you that a functional type-class replacement would be
more consistent, and would be a sensible aim for the future.
but current Haskell has type classes, and current practice does use
MPTCs and FDs; and you don't do your own case any favours by
trying to argue against others advertizing and investigating their's.
for instance, ATS should just be special syntax for a limited, but
possibly sufficient and more tractable form of MPTCs/FDs, and
as long as that isn't the case in practice because of limitations in
current implementations or theory, we don't understand either
feature set sufficiently well to make any decisions.
cheers,
claus
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
