DRAFT: Haskell' status update

[Claus Reinke]

> Nevertheless, the committee feels that we cannot have a Haskell' without
> some way to resolve ambiguities when using multi-parameter type
> classes, be it Functional Dependencies (FDs) or Type Families (TFs).

agreed!

>   - "Haskell' alpha" will be a complete language specification,
>     including all the modifications and additions we want to make
>     to the language *except* for FDs or TFs.

that should at least allow for some necessary progress.
 
>   - Haskell' will follow afterward, adding either FDs or TFs.

that seems to suggest that Haskell' is going to be *the* standard,
so it better be very good, and not leave out anything important,
even if it is as recent as TFs. 

strangely, i never had such great expectations from this process - 
instead, i expected Haskell' to be *one in a series* of standards, 
documenting the current state, not any (supposedly) final state. 
it should have come out long ago, and should be well on its way 
to become obsolete in a few years (though not immediately, if possible).

in line with those expectations, i'd be happy with a Haskell' beta,
if it were to *standardise*, but *not prescribe* FDs and TFs and 
whatever other type system extensions have been in common use 
for a long time now. no Haskell' beta implementation would be
required to implement either FDs or TFs or overlap resolution
or closed classes or .. . but if i write {-# LANGUAGE TF #-}
and the implementation doesn't complain, it'd better conform to
the standard for TFs. 

currently, that is simply not the case, with LANGUAGE pragmas 
supported (and interpreted differently) by more than one implementation 
suggesting a *false* sense of standardisation and portability.

> The motivation for this two-stage approach is that we can make progress
> on all the other parts of the language without being blocked on the type
> system, we can start work on implementing Haskell' alpha in our
> compilers, users can start using the new standard, and we can gain some
> experience with using it in practice.

yet another option would be to standardise improvement as a means 
of reducing ambiguity, and simplification as a means of rewriting 
constraints, leaving open specific forms of specifying such improvements 
or simplifications - a bit like a language-standard "API" for adding 
features (perhaps there could even be a corresponding standard API 
for extending standard-conformant implementations) [1]. 

then there could be an addendum specifying FDs as one particular
instance of enabling such improvements, and any implementation
supporting {-# LANGUAGE FD #-} would have to conform
to that addendum.

and anyone wanting to support other forms of improvement
(records, subtyping, ..) could program to that implementation 
extension API..

> Thanks for your patience :-)  And rest assured that progress is being made!

thanks for your update! (frankly, i had written off haskell prime;-)

haskell prime is dead! long live haskell prime!
claus

[1]  M. P. Jones. Simplifying and improving qualified types. 
    In FPCA '95: Conference on Functional Programming Languages 
    and Computer Architecture. ACM Press, 1995.

    http://web.cecs.pdx.edu/~mpj/pubs/improve.html