[clean-list] Wish list, part 3

[Marco Kesseler]

things are a bit quiet here on the Clean list, so here are a few more 
items for my wish-list. If anyone has wish-list items too, or has 
reasons why something should NOT be on this wish-list, please post it 
to this mailing list. Expressing support for a particular item is 
also welcome. I think that a generally accepted wish-list is a good 
starting point for getting some work organised (eventually). I am not 
pretending that I know what is good for everybody, so discussions are 
welcome. 

That does not mean that I actually know who is going to do the 
implementation work..., that's another matter. 

Some time ago, there was talk of organising an implementer/user 
meeting (in Nijmegen). Any news on that?

--------------------

onto the wish list.

already present:
- better interfacing with imperative (object-oriented) languages (at 
least
  allowing Clean to be called from these languages).
- support for exceptions

Wish 3:

compile-time evaluation of constant expressions. This is important 
for efficiency and readablility.

I can remember two (similar) cases where this would have been useful 
in my code:
- fixed-point numbers: it is easy to write a macro/function FIX that 
transforms floating point numbers into the corresponding fixed-point 
representation, but using it is currently very inneficient, because 
it does not get evaluated at compile-time.
- Unicode: one can define a function Unicode that transforms an 
ordinary ASCII string to its Unicode equivalent, but currently, this 
does not get transformed into a Unicode literal.

Wish 4:

conditional compilation. Clean is not as platform independent as one 
would like. This is not so much due to the language, as to the 
(un)availability of libraries for various platforms. Apart from this, 
I usually have a hard (i.e. boring) time enabling/disabling all kinds 
of debugging/testing code.

Wish 5:

This falls in the category that dutch people call 'klein leed' 
(little sorrow). I think that 'symbolic simplicity, convenience and 
consistency' kind of sums it up, or:

what's in a symbol, that its name...

I know that getting this one right can be hard, but I feel things 
have gotten a bit out of hand in Clean. The same complex syntactical 
interactions that make this difficult to solve, also make things 
difficult for programmers to grasp. What am I talking about?

- the list of cryptic keywords is growing steadily, and sometimes in 
seemingly ad-hoc ways. Take for example the recently added support 
for strict lists. This feature is important, but it comes with a new 
set of denotations, which does not make things simpler. One would 
think that the overloading mechanism should be able to avoid many of 
this (more about overloading in a later message). Isn't it possible 
to just stick with <- in list comprehensions, instead of <-, <-: and 
<|-. Why do I have to write [!, [# or [| if the type of my function 
already specifies what kind of list it is dealing with? These things 
make it hard to change from ordinary lists to strict ones.

- I know there are good implementation reasons to distinguish tuples 
from records and arrays from lists. From the same implementation view 
one may argue that records and arrays are similar. Well, the Clean 
syntax supports the implementers view, but it does not support the 
programmers view for whom tuples and records are conceptually the 
same, and lists and arrays are at least related.

- Related to the previous: ASCII symbols are a scarce resource. It is 
a pity that square brackets have been devoted to lists, which are 
just an algebraic type, and thus do not need any special notation, 
except for their own constructor. The result of this choice is 
apparently that square brackets cannot be used to identify array 
types anymore, which is what some well-known languages use. And note 
that Clean itself uses square brackets for array selection as well.

- The clean rules for identifiers are such that they can either 
consist of ordinary characters, or of some special characters, but 
not both. Otherwise the compiler has trouble interpreting things like 
'n+1'. In my opinion this is a pity, because:
a) I have no trouble writing 'n + 1' (i.e. with spaces, which I often 
do anyway)
b) I prefer a simple rule that all symbols are separated by 
whitespace (and brackets)
c) I would very much like to markup my symbols like >add<,  >sub< for 
dyadic operators, or symbol+, symbol*, symbol? for parsing functions, 
or @node for labels, or <elem> and </elem> for constructors. 
d) I don't believe that things like (<?@) make your code any more 
readable (taken from parser combinator stuff).

regards,
Marco