the MPTC Dilemma (please solve)

[Claus Reinke]

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