DRAFT: Haskell' status update
Those on the Haskell' mailing list may have seen recent signs of activity on the Haskell' front. I thought I should clarify the current status, and update the community on our plans for Haskell'. The main sticking point in the design of Haskell' has been the type system: namely whether Haskell' should have Functional Dependencies or Type Families. This issue is still undecided, although the experts are hard at work on developing a stronger understanding of Type Families in particular. 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). For one thing, a great deal of existing code uses FDs or depends on code that does, so unless we adopt one of these extensions all this code will still exist outside of Haskell', and that is far from ideal. So we decided to proceed in two stages: - "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. - Haskell' will follow afterward, adding either FDs or TFs. 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. On the process side of things, we're now tracking the status of all language design proposals on this page: http://hackage.haskell.org/trac/haskell-prime/wiki/Status and as usual all the Haskell' resources are on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki The committee have been discussing various proposals amongst ourselves over the past few weeks, with the goal of making as many concrete decisions as possible. However, the general policy is still for technical discussions to take place in public, as far as possible. Changes to the status page are sent to the public mailing list, and we welcome comments on any of the issues, regardless of status. Thanks for your patience :-) And rest assured that progress is being made! Cheers, Simon (and the Haskell' committee)
Simon Marlow wrote: Subject: DRAFT: Haskell' status update of course, that shouldn't have said "DRAFT". Cheers, Simon
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
participants (2)
-
Claus Reinke -
Simon Marlow