[qv]<IDL>History>DesignMemos.dm!1>Design.DeepIssues

In general, there are three levels of change we can make to the system during the INTERLISP implementation: Alteration within specific functions; Redistribution of capability between functions (on the user visible level this involves task analysis); and Changes to the underlying structures. This memo describes a set of design issues at the last of these levels - problems with the IDL PPL system whose solutions raise fundamental questions as to the basic organization of the system. For each of these issues, a brief description of the problem or alternative desirable behaviors is presented. Some alternative solutions or estimates of the importance of the problem are also offered, but these are intended to be exploratory, rather than definitive.

1. Label handling. Current implementation is very PPL dependent - uses strings which are not good - doesn’t allow many expressions which seem reasonable (in particular the attaching of structure to the array). On the other hand, there are inconsistencies in these "reasonable" expressions. In any event, there are problems in attaching labels to their arrays with respect to garbage collection or file resident arrays.

2. Expression compilation; generators. Extreme inefficiency of array generation expressions in the current system e.g. chi square. There is a better way of thinking about it. Problem is the extent of the changes to the system required. Then again, an awful lot of hair of MAP might go away.

3. MAP/Angle. This is a very hairy, rather slow piece of code. It could perhaps be radically simplified by having each array be conceptualized as having an infinite number of dimensions with extent on only a fixed number. This would be nice anyway because of orientation of vectors. Doesnt cost anything in and of itself, but the question is how it fits in with the rest of the world.

Another problem with MAP is the mechanics of its intervention into function invocation. Currently, this is done by having a dummy entry point for each mapped function - which is a mess. Can we type a functions arguments so that MAP automatically intervenes on argument/parameter dimension mismatch? Or perhaps attach the argument information somewhere (property list?) where the evaluator will always look? We must get in seamlessly so that userfns map straightforwardly.

4. It has been suggested that one wants to add a printing form (i.e. one which would determine the print widths etc) to the columns of an array - perhaps other stuff (range checks etc) as well. More generally, this raises the whole question of the value labels - which function as a version of that form and other relations that might be attached to a segment of a data array. Perhaps one could even allow heterogenous data types - any payoff here?

5. Ragged objects. Yuk! [Or, more elegantly, I don’t see any compelling argument that would justify the upheaval that the introduction of these would cause.]

6. The problem of how to deal with file resident arrays must be faced. Not sure how to do this in the LISP environment - perhaps the PPL solution (not very sound as it was never tested) is not appropriate.

7. The cost of functions that produce array results can be very large because of the size of the objects being produced. Perhaps we should make sharing the default and trap and copy only on assignment.