combining records and arrays

5.4: adda/dstr/combining records and arrays:
5.31: summary:
. records and arrays in the Python language are seen as
2 different operations even within the same object;
and, that is a feature that can't be emulated
if records and arrays are seen as
2 methods for accessing the same components;
eg, you couldn't have separate components for
agg.field and agg# field .
. we can use arrays as an extension of records,
so if the array has no such item agg# field,
then it checks for an agg.field;
and conversely, if there's no agg.field,
then it checks agg# field
-- always giving priority to the accessor in use,
so that there can exist both agg.field and agg# field .
. if there exists an agg.field
and we'd like to create an agg# field,
we can do so by making the assignment: agg#(field)`= ... .
. if we haven't yet made that assignment,
then reading agg#field will default to returning agg.field .

. records and array notation have been seen as interchangeable;
but, Python's ability to provide both
dictionaries and record fields,
has me wondering if I can do that,
and still use them interchangeably .
[5.30:
. an array is simply a record with an additional constraint:
all the components or fields are the same type;
however, with oop, arrays can be varying type
as long as all fields have a common supertype .
. conversely, record field selection can be computed
just like arrays use indexing for selection
if there is some function that returns symbols,
(if the symbol isn't a field then there's a range exception). ]
. the record notation has been for
any time one wants to use a literal field name
whereas the array syntax has been for
computing the field name(ie, with a non-literal)
but of course computing included the use of literals .

. the syntax for doing both would be .< .( ...), #().t >
(that's a class definition with nothing but
record and array accessors).

. we want all adda symbols to be typed,
so, to allow our arrays to be like python's dictionaries,
we need a type called "(any) (same as Object)
to indicate an escape from a specific type .
. then our pythonic symbols are typed .tall
(pointer To ALL)
and that type includes the pythonic array access:
#(hashable).any .

. if the domain is floats
then interchanging {rec, array} is confusing
because the dot is used as both a field selector
and the float's fraction selector;
eg, does x.1.2 mean x#(1.2), or x#(1, 2) .
. so then, another rule of record type is that the
domain type must be a symbol, not any hashable ?
. it would be better if records and arrays were
not interchangable, except that
if you would like to compute a record's name,
you can do that with array notation
but if you use a record's field selector (x.field)
then you mean x has been declared a record
... uh,
if a symbol can be both record and array
then record names cannot be computed,
because, that requires the use of array notation,
but then the reader will be getting confused:
are you referring to your symbol's record fields
or to its array components ?!
[5.30: nevertheless, it could work because,
we are saying that the array and record
are accessing the same fields;
ok, but,
didn't you want your record's fields to be typed?
. we could say that by defining record fields,
we're reserving those fields to be a particular type,
so then if the array assigns them some other type,
that raises an exception .]

another way record's can be like arrays is you say ...enum,
.( .. .trafficlight: .t ) as shorthand for
.( black, red, yellow, green: .t )ie,
in a record declaration,
.. can be followed by an enum type name
you can also list integer ranges?
. uh,
as part of keeping the language simple,
if we want to use range notation,
we should declare it to be an array .
5.30:
. if we didn't declare the domain to be type .type,
then types could still be shorthand for sets of values,
so we could give assignments like this:
A#( .trafficlight)`= {0; 1; 2; 3}
as shorthand for
A#{black; red; yellow; green}`=  {0; 1; 2; 3} .