semantics and optimizations

[Alan Grover]

Please make the useage of arrays, and lists similar. I think that the
implementation differences have colored the syntax inappropriately. Just as
you allow nearly identical useage of graphs and functions (with very
different implementations), arrays and lists should be treated as similar.
I believe tuples and records can be incorporated into the same treatment.

I think there is an abstraction here:

We have a particular type (list) which is fully generalized, and we realize
that the full generalization has performance implications.

We'd like to use the same type in a restricted way that allows significant
performance increases (e.g. array, which trades off insertion speed for
fast iteration).

We'd also like to use the same type mapped to a foreign representation
(e.g. record to struct), accepting restrictions to obtain the mapping.

We still want a lot of compile time checks to prevent misuse, and we don't
want to greatly increase the programmer's burden (during writing, or during
maintenance/examination).


I think it would be wise to recognize this abstraction and let all of the
above useages be of the same useage-type (e.g. list), but allow the
specification of the implementation. I think it is proper to seperate these
things (as you did for graphs and functions).

To help with the burden of using different implementations, the compiler
should be able to indicate a useage inconsistent with the purpose of a
specialized implementation (inserting into an "array"). Annotations in the
source should acknowledge these misuses ("I know it is slow") and suppress
the compiler warnings.


One way of implementing this abstraction is the solution used in STL
(Standard Template Library for c++). For example, see the "container"
abstraction and various implementations. That solution did not provide for
managing the programmer's burden, however.

That solution appears to require a more powerful overloading ability than
Clean 1.2 has. But God forbid you should actual implement things the same
way!

Your uniqueness type is an example of doing this for one kind of restricted
use.

---
Akin to the case of lists, I believe that integers have a flawed
implementation. You allow for the fully generalized useage of lists, and
provide a more efficient specialization when needed (i.e. arrays).

The same approach should be used with integers (and other numbers). That
means infinite precision implementations as the general case, and
restricted/specific precision when needed (8bit, 16bit, 32bit).

I intuit that sometimes the compiler could substitute a specialized
implementation for the general case.

---

---
"Alan Grover, Technical Pb" awgrover@umich.edu
+1 (743) 647-5778
Project Leader
Health Media Research Lab, Cancer Center
5D04 North Ingalls Building, Mail Stop 0471
300 North Ingalls
Ann Arbor, MI 48109-0471