DDC/ReleaseNotes-Alpha1.1

< DDC

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 constants true# and false#.

• 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

Recent content is available under a simple permissive license.