DDC/ReleaseNotes-Alpha1.1
Jump to navigation
Jump to search
New features vs Alpha1
- Support for linux-x86_64 and darwin-x86_64 build targets, thanks to Jared Putnam.
- The parser has been completely rewritten using parser combinators.
- The -make flag now does a full dependency driven build/rebuild. This also descends into the base libraries, which makes them much easier to work on.
- Preliminary support for constructor classes, which is used to implement Monad, Functor and Foldable.
- Partial (ticket) support for monadic do notation, so the following works:
many1 :: Parser tok a -> Parser tok [a]
many1 parser
= do x <- parser
rest <- many parser
pReturn (x : rest)
- Unboxed boolean type
Bool#
and constantstrue#
and#false
.
- Field punning makes adding projections to a data type a brease:
data Set a = ..
project Set with
{ empty; singleton; size ... }
empty = ...
singleton = ...
size = ...
- The offside rule now applies to import lists, ie:
import Data.List
Data.Maybe
Data.Set
Known Issues
Being an alpha release there is enough implemented to write some programs, but there are a few missing features and some other things to look out for:
- Dictionary passing for type-classes is not finished.
- Inferred types may not have type-class contexts, neither can class and instance definitions. (ticket)
- eg: this is ok
instance Show (List Int) where
...
- but this is not:
instance Show a => Show (List a) where
...
- Type class instances are not checked against the class definition.
- If an instance has more effects than the definition, or the regions are not as fresh, then the compiler will panic when type checking the core. (ticket)
- Invalid uses of unboxed data are not checked.
- The runtime system does not support functions being partially applied to unboxed arguments. Nor does it support unboxed data being free in the closure of a function, or being used as the argument to a polymorphic data type. None of these are checked, and all will result in a runtime crash. All other uses should be fine. (ticket)
- Various intra-module problems aren't checked.
- Exporting mutable data containing monomorphic type vars is unsound because client modules could update it at different types. (ticket)
- Other malformed source programs may result in a compiler panic, but should not cause problems at runtime.
- It's a bit slooow..
- Not for any fundamental algorithmic reason, but because all the work has been put into fixing bugs and getting it off the ground - and not so much fixing space leaks and optimising the compiler itself. For example: When importing the Prelude, the entire set of module interface files needs to be parsed and added to the type graph. We'd likely get a big improvement by only loading what's needed for each particular program. (ticket)