Difference between revisions of "DDC/ReleaseNotes-Alpha1.1"
< DDC
Jump to navigation
Jump to search
Line 1: | Line 1: | ||
'''New features vs Alpha1''' |
'''New features vs Alpha1''' |
||
− | * |
+ | * Support linux-x86_64 and darwin-x86_64, thanks to Jared Putnam. |
− | * The |
+ | * The parser has been completely rewritten using Parsec 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. |
* 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. |
||
+ | |||
+ | * Monadic do notation. |
||
+ | |||
Revision as of 08:08, 3 July 2008
New features vs Alpha1
- Support linux-x86_64 and darwin-x86_64, thanks to Jared Putnam.
- The parser has been completely rewritten using Parsec 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.
- Monadic do notation.
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)