|
|
# Principles for Haskell'
|
|
|
|
|
|
|
|
|
|
|
|
With all the suggestions for additions to Haskell Prime, we have to find a good way to decide what's in and what's out. I recommend we maintain a set of principles to guide us. That will help us finalize on a language design that feels coherent, rather than one that feels cobbled together. Feel free to add/edit these principles if they don't reflect reality or our intents.
|
|
|
|
|
|
|
|
|
## Haskell Prime
|
|
|
|
|
|
|
|
|
|
|
|
Haskell Prime builds on Haskell-98, focusing on things designed to make better for practitioners. It is complete enough to be stable over time, so that tool writers write tools for it. It is mainly a consolidation of progress since Haskell 98. The default assumption is that it will contain only features that have been implemented and widely used, except when more radical features are needed to meet the needs of practitioners.
|
|
|
|
|
|
|
|
|
## Backwards Compatibility
|
|
|
|
|
|
|
|
|
|
|
|
Haskell Prime will be largely backwards compatible with Haskell-98, but it may reject some Haskell-98 programs where that provides tangible benefit to the design (e.g. design simplification, removal of ambiguity etc.) Implementations may choose to remain backwards compatible (by retaining a Haskell98 flag, for example).
|
|
|
|
|
|
|
|
|
## Learning Curve
|
|
|
|
|
|
|
|
|
|
|
|
Haskell should be beginner friendly e.g. for professional programmers new to Haskell. Furthermore, it should be straightforward to master Haskell.
|
|
|
|
|
|
|
|
|
## Definition
|
|
|
|
|
|
|
|
|
|
|
|
Haskell' will be clearly and rigorously (but not necessarily formally) described. It should be possible for programmers to work out whether
|
|
|
their programs are legal, and what they mean, by reference to the description alone.
|
|
|
|
|
|
|
|
|
## Syntax
|
|
|
|
|
|
|
|
|
|
|
|
It's fine to have lots of ways to express the same concept, so long as the variations get used very frequently. Rarely used notations should be omitted.
|
|
|
|
|
|
|
|
|
## Complexity
|
|
|
|
|
|
|
|
|
|
|
|
There is a difference between deep complexity and superficial complexity. The bar is much higher to accept the first. We strive for orthogonality of features unless there is a compelling case otherwise. There are very few places where the practitioner has to memorize a list of special cases.
|
|
|
|
|
|
|