This message constitutes a design memo based on this afternoon's discussions, despite it's not being formatted with full glory.

Naming convention:  Elements of rows are to be refered to as RELTS (pronounced "rowelts") and elements of arrays as AELTS (pronounced "arrayelts").  These names will be used consistently to generate composite names for functions.  Thus, a function which FOOs an RELT is to be called FOORELT or RELTFOO.  Current examples are RELTTYPE, GETRELT, and SETRELT (and the corresponding functions for AELTs).

Pointers into arrays:  The problem is to get a pointer to an element that can be used to both read and store, without allowing its type to get detached so that a FLOAT value is mistakenly stored into the middle of an INT array.  The new resolution is to define a type AELTPTR with fields SOURCE and PTR which is returned by functions like NEXT and hard array subscripts.  SOURCE is defined to point to the array from which the element comes, and PTR is a pointer thereto.  The functions GET/SETAELT will take two args: an array and an aeltptr (if the latter is thought of as a description of the element that is to be referenced, then there is some symmetry with the arg fields of GET/SETRELT).  The type dispatch for FETCH in GET/SETAELT will be done on the basis of the type of the arrayarg.  During system debug, the aeltptr will be declared (in GET/SETAELT) to satisfy (EQ aeltptrarg:SOURCE arrayarg), thus requiring that AELTPTRS are only applied to the object from which they were created.  After debugging is complete it will be presumed that no aeltptr is ever misused and aeltptrs will then compile as their PTR fields (i.e. as LISP pointers) and the type dispatch will continue to be done from the type of the array.  This may or may not be known at compile time.  To aid compilation when it is, the array accessfn AELTTYPE will be made clever enough to retrieve the type field from satisfies expressions of the form (satisfies (eq a:aelttype 'integer)).  [This will be recognised as an ad hack solution for a previously discussed general problem.]

Default values for rows:  The value of an uninitialized row cell is specifically undefined i.e. if the CREATE does not specify an INIT value, the cells may not be referenced without first being set.  This will be enforced by intermittently changing the default value used during debug.

TTAB: These have been redeclared to an object of a new type - a ROWPTR.  ROWPTRs will obey most of the defined semantics for ROWs (i.e. will honor GETRELT etc.).  The storage format of this type is as yet undefined, but the intention is that it can be used freely whenever a block of pointers is required.  This is required by the TTAB field in order that the selectors be directly accessible by indexing by the dimension to which they are being applied.

All changes described in this memo have been installed unless messages to the contrary are received.

Beau	                                           March 22, 1977  7:16 PM