DDC/ReleaseNotes-Alpha1.1
This is outdated information. The DDC project has moved to http://discus-lang.org
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.
- Support for irrefutable patterns.
- 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#
andfalse#
.
- Field punning makes adding projections to a data type a breeze:
data Set a = ... project Set a with { size; toList; ... } size = ... toList = ... main = ... someSet.size ...
- The offside rule now applies to import lists, ie:
import Data.List Data.Maybe Data.Set
- More example code, including a 2D collision detection system (src) and a simple raytracer (src)
Known Issues
Being an alpha release there is enough implemented to write some programs, but there are also 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)
- 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)
Old News
ReleaseNotes for Alpha1