Difference between revisions of "DDC/ReleaseNotes-Alpha1"
< DDC
Jump to navigation
Jump to search
m (To be deleted if no new content appears) |
|||
(4 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
+ | '''This is outdated information'''. The DDC project has moved to [http://discus-lang.org http://discus-lang.org] |
||
− | = Missing Features = |
||
+ | |||
+ | |||
+ | |||
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: |
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: |
||
Line 21: | Line 24: | ||
* Type class instances are not checked against the class definition. |
* Type class instances are not checked against the class definition. |
||
− | :If an instance has more effects than the definition, then the compiler will panic when type checking the core. [http://code.google.com/p/disciple/issues/detail?id=82 (ticket)] |
+ | :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. [http://code.google.com/p/disciple/issues/detail?id=82 (ticket)] |
* Invalid uses of unboxed data are not checked. |
* Invalid uses of unboxed data are not checked. |
||
Line 27: | Line 30: | ||
* Various intra-module problems aren't checked. |
* 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. [http://code.google.com/p/disciple/issues/detail?id=125 (ticket)] |
* Other malformed source programs may result in a compiler panic, but should not cause problems at runtime. |
* Other malformed source programs may result in a compiler panic, but should not cause problems at runtime. |
||
Line 33: | Line 36: | ||
* It's a bit slooow.. |
* 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. [http://code.google.com/p/disciple/issues/detail?id=91 (ticket)] |
: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. [http://code.google.com/p/disciple/issues/detail?id=91 (ticket)] |
||
+ | |||
+ | [[Category:Pages to be removed]] |
Latest revision as of 11:57, 19 April 2021
This is outdated information. The DDC project has moved to http://discus-lang.org
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:
- Only 32bit machines are supported.
- The GC used to work on 64 bit machines also, but it hasn't been tested for a long time. (ticket)
- 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)