Commit b6ff9814 authored by Martin Wierich's avatar Martin Wierich
Browse files

*** empty log message ***

parent ca6cbbce
This file describes differences between Clean 1.3.x and Clean 2.x
This file describes differences between Clean 1.3.x and Clean 2.x. It is aimed
to help you to port Clean 1.3.x programs to Clean 2.x
First of all: Clean 2.x is not downward compatible with Clean 1.3.x. Probably
you have to change your 1.3.x sources to get them through the Clean 2.x
......@@ -15,7 +16,7 @@ New Features in Clean 2.0
-------------------------
Clean 2.x has dynamic types, multiparameter type classes and generic classes.
For these items we see the Clean language report.
For these items see the Clean language report.
With Clean 2.x cyclic dependencies between dcl modules are allowed.
......@@ -28,21 +29,9 @@ can enforce strict evaluation using the strict hash let (#!).
Differences in the Type System
------------------------------
1.
For multiparameter type classes a small change in the syntax for instance
definitions was necessary. In Clean 1.3.x it was assumed that every instance
definition only has one type argument. So in the following 1.3.x instance
definition
instance c T1 T2
the type "(T1 T2)" was meant (the type T1 with the argument T2). If this was
the intention then this should be written in Clean 2.x as
instance c (T1 T2)
otherwise T1 and T2 will be interpreted as two types.
1. Array handling has become different, see section "Differences in the
Standard environment
2.
There is a difference in resolving overloading. Consider the following code:
......@@ -110,26 +99,16 @@ Differences in the Type System
is not valid.
5.
There was a bug in the uniqueness typing system: Records or data constructors
could have existentially quantified variables, whose uniqueness attribute
did _not_ propagate. So it was possible to write
f :: *{Int} -> Int
f a
#! a0 = a.[0]
a = { a & [0] = a0+1 }
= a.[0]
:: T = E..x: C (x->Int) x
getInt (C f x) = f x
Start
# myObject = C f {0}
= (getInt myObject, getInt myObject)
which resulted in (1,2), which isn't that much referential transparent. This
bug has been solved in Clean 2.x.
The Clean 1.3.x compiler has chosen lazy arrays whenever there was a choice.
The Clean 2.x compiler will complain in these cases that internal overloading
could not be solved. E.g.
Start = size {1}
is accepted by Clean 1.3.x but not by Clean 2.x.
6.
Some bugs in the uniqueness typing system were fixed.
Differences in the Module System
--------------------------------
......@@ -245,6 +224,21 @@ Miscellaneous Differences
-------------------------
1.
For multiparameter type classes a small change in the syntax for instance
definitions was necessary. In Clean 1.3.x it was assumed that every instance
definition only has one type argument. So in the following 1.3.x instance
definition
instance c T1 T2
the type "(T1 T2)" was meant (the type T1 with the argument T2). If this was
the intention then this should be written in Clean 2.x as
instance c (T1 T2)
otherwise T1 and T2 will be interpreted as two types.
2.
Anonymous uniqueness attributes in type contexts are not allowed in Clean 2.x.
So in the following function type
......@@ -252,7 +246,7 @@ Miscellaneous Differences
simply remove the point.
2.
3.
There are differences in some libraries. See the library's documentation.
The Preprocessor
......
......@@ -150,6 +150,9 @@ imported_decl_to_opt_string all_expl_imp_decls dcl_ident dcl_index STE_Type def_
_
-> dcl_ident.id_name)
= (Yes dcl_string, dcl_modules)
imported_decl_to_opt_string all_expl_imp_decls dcl_ident dcl_index STE_Generic def_mod_index
dcl_modules
= (Yes ("generic "+++dcl_ident.id_name+++"(..)"), dcl_modules)
// only for portToNewSyntax
type_to_string (TA {type_name} _) = possibly_replace_predef_symbols type_name.id_name
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment