[clean-list] Wish list, part 3

[Marco Kesseler]

Hi Rinus,

thanks for your remarks. Below you will find some additional ones. 

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

This strongly depends on what you are doing. In a more general 
context this is about partial evaluation.

I mentioned fixed-point numbers. These seriously increase performance 
for JPEG decoding. Unfortunately, a readable notation (say 
FIX(3.1415)) decreases performance considerably, because it involves 
a floating point -> integer conversion. Even specifing these numbers 
as shared graphs is too expensive (I tried). Actually, the constants 
derive from expressions like "cos(k*PI/16) * sqrt(2)" for k = 1 to 7, 
which would be the most readable by far, but also the least efficient.

So, for the 10% of your (possibly scientific) code that runs 90% of 
the time, this seems pretty useful.

As to Unicode literals: I have not done any performance tests, but I 
imagine that this could be important too. Consider a parser for 
example, that frequently needs to match against a set of Unicode 
literals. Contant graphs may be allright here, but probably do not 
lead to the most readable code, as they introduce definitions like:

helloWorld =: Uni "Hello World"
hitAnyKeyToContinue =: Uni "Hit any key to continue"

>Anyhow, we are putting more effort in program transformations (fusion
>algorithm).
>We have to, because generic programming not only has advantages.
>> ...
>> Wish 5:
>> ...
>> - 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.

I think the situation is more or less as follows:
- specifiying types is important for readability, but
- you may go mad if you'd have to do it everywhere

Anyway, there are a lot of places that types do get specified. Isn't 
it possible to come up with a scheme that awards people for this? So 
if they do specify a type, they:
- do not have to worry about [!, [# or [|
- do not have to worry about <-, <-: or <|- (why not <-| BTW?)
- do not have to specify a record type if using a field name that is 
present in multiple records
- other goodies?

>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 understand the trouble of history. Many people do not like change. 
On the short term it is counterproductive. But I have also 
encountered plenty of history that only a complete rewrite could 
rescue. In the grand scheme of things I wouldn't mind some short-term 
trouble if it leads to a better Clean.

Note that switching to overloaded syntax everywhere also means a 
considerable rewrite for existing code. Wouldn't it actually be more 
compatible if we could have [] for the overloaded case?

By the way. I noticed that StdOverloadedList.icl contains much 
duplicated code. Will there be a solution for that?

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

That is an extra reason for avoiding special syntax where none is 
needed.

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

I think the basic stuff should be rather fixed. At the same time it 
should be kept as minimal and simple as possible.

>Suggestion are welcome....

>> - The clean rules for identifiers are such that they can either
>> consist of ordinary characters, or of some special characters, but
>> ...
>...I understand and I agree.
>I have to think what we can do about it.

Thanks. Also see some earlier mails on the clean list.

>We will soon release a 2.0 version for Linux and Mac.
>In general it does not take much work to make a new release of a compiler
>for either Linux or Mac.
>Most of the work is in the libraries, more precisely in the IO libraries.

Would it be possible to schedule future releases of the compiler 
closer together, no matter what the state of the libraries is for 
various platforms? I am quite sure that may people (in particular the 
Linux folks) would prefer this.

>It would be great if someone would make the port for Linux.
>All source code is on the net and we will be glad to help you if you have
>any questions.

Personally, I think this sounds reasonable. Even if you would have 
the resources, I think it would be a good idea if others get involved 
(and considering the latest on the clean list, it seems there are 
people willing to do so, or similar).

groetjes,
Marco