Algebraic types and subclassing

[rinus plasmeijer]

>As if this message weren't enough, I'll propose a few more extensions to the
>Clean language, not related to the above topic.
>
>- Language level support for pre and post conditions.

We have started research to investigate the possibility to add conditions add certain points with the idea that the "compiler" can proof the correctness automatically.
However, as you said, you hit on undecidability very soon.
Stil I have some hope that we can work out a workable tool.
This will take some years though....


>- The ability to define functions of arity exceeding 1 in more convenient
>ways:
>    You can define:
>        Add :: Int Int -> Int
>        Add x = \y -> x + y
>    But it would be nice to be able to define
>        Add = (+)
>    Sure, you can do this by defining Add :: (Int Int -> Int), but that's
>not the same.

What is the difference? It does not matter how one defines Add, one can used it curried as one like?


 This is convenient when one wants to define (>>=) = (`bind`),
>or even:
>        myParser :: Parser foo bar
>        myParser x = ...
>    Instead of
>        myParser = p
>            where p x = ...
>    This may cause some problems, but it solves some too.
>
>- The use of more classes in the standard library

In the new StdEnv more functions are defined overloaded.
Any suggestions / contributions for library extensions are welcomed...

>- Language level support for ADTs. Data hiding is pretty tricky without
>this. And you *can't* hide types without this.

It is possible to hide types using the module structure of Clean (exporting the type constructor, but not its definition.


>- Make the language more orthogonal. Clean is already beautifully small, but
>I think it could be a bit smaller. An example is the case construct. Perhaps
>I'm missing something, but couldn't case be defined like:
>    case` :: a [(a, b)] -> b | Eq a
>    case` x l = snd (hd (filter (((==) x) o fst) l))

The case construct is indeed an extension a programmer could define (eg by defining a local function using pattern matching).
Like "if" the case construct is added for convenience.
By the way, in the new Clean compiler the case construct is a part of the Clean kernel language and patterns not: they are translated to a case.

>- OK, this is a pipe dream, but I'd like to see first class types (i.e.,
>type can be passed as arguments to functions). This eliminates the need for
>a special construct for dynamic types, special constructs for parametered
>types (e.g., :: Parser s r :== [s] -> [([s],r)]), etc.

This is indeed an option.
For the time being we have chosen for incorporating dynamic types instead
stressing the combination of a type and an object of that type.
However, you can play with dynamic types as such because "w = w" is a legal representative of an object of any type.

>- Another pipe dream: reflection. I think reflection might be a useful
>feature in some contexts.

What do you mean by this?

>- Support for all major platforms (Unix too!)

We have to make choices do to lack of manpower (even though the group is growing).
Nevertheless, the next release of Clean (1.3) will also appear on Unix.
It is the IO library which is causing too much work, i.e. the lack of stability of OS GUI primitives on platforms like Unix / Linux.

>- Standard libraries with access to environment variables and the like.

Yes, I want this too.

Greetings,

Rinus