[clean-list] Wish list, part 3

[Rinus Plasmeijer]

Hi Marco,

>
> 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).

Thanks for starting this discussion. We welcome any suggestions for
improving Clean.
However, turning a wish list into reality is something else.
Implementations always take much more time then estimated.
And the priorites of our team lies in research.
So, it might take some time before we have found the resources for actually
doing something.
I hope you understand....

 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?


I simple only got a very few reactions.
If there are enough people interested (say more than 15 people) , I will be
glad to organize a meeting.


> --------------------
>
> onto the wish list.
>
> already present:
> - better interfacing with imperative (object-oriented) languages (at
> least
>   allowing Clean to be called from these languages).

I agree that it would be nice if the interface would be improved.

> - support for exceptions

Also high on my list. A student from Eindhoven University is going to do his
master thesis on this topic.

>
> Wish 3:
>
> compile-time evaluation of constant expressions. This is important
> for efficiency and readablility.

Is compile time evaluation of constant expressions realy important for
efficiency?
Anyhow, we are putting more effort in program transformations (fusion
algorithm).
We have to, because generic programming not only has advantages.


>
> 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.

I agree. Would be nice to have.

>
> 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.

In principle I agree, but I do not know how to solve it.
We try to infer types where possible, and to make this possible, we
sometimes need to introduce additional syntax.
A solution would be not to infer types, but I don't think people are happy
with that.
We are also faced with history.
The [] are already used for lazy lists. If we could start fresh it would be
better to reserve this notation for the overloaded case.
Anyhow, what you currently can do is use the overloaded syntax everywhere.
This makes it very easy to switch to any list structure you like....

>
> - 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, but not the same....

>
> - 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.

Brackets are a very very scarce resource. But what can do about it?
I can imagine a language in which almost all symbols can be freely used by
programmers.
But would that make a program more readable?
Suggestion are welcome....

>
> - 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).

I understand and I agree.
I have to think what we can do about it.

Greetings,

Rinus