arrays are records are tuples

8.19: adda/dstr/array and record syntax as modes of access:
if ( x.y ) and ( x#y ) are both valid
regardless of whether x is defined as an array or record;
this ignores an idiom where
arrays represent lists of items,
while records represent items with named parts;
. well, my way lets you do it both ways,
but it should be admitted that the writer's freedom
is inevitably the reader's headache .

adda/dstr/array vs record precedence:
. if you have x#y.z
does it mean x#(y.z) or x#(y).z ?
my first impression is that y.z is the tightest binding;
ie, it means x#(y.z);
also, (x#(y) = x#y) only when y is an atom,
and you could argue that y.z is not an atom:
it's a sort of address-addition operation; [11.16:
but, of course, that would be a stretch!
it's more intuitively seen as a style of atom naming .
. finally, consider how functions and arrays
should be similar;
( f x.y ) should be seen as a variant of
( a# x.y ); therefore, the parsing is ( a#(x.y) ). ]
. x.y#z is unambiguous: x has component y,
which is an array taking parameter z;
ie, it's parsed as ( (x.y)#z ).

8.20: adda/dstr/arrays are a species of record.type:
. an array is generating a list of component names,
and then declaring them all to be the same type .
. records are a generalization of this,
where a generated list of components
can have a variety of types .
. in fact, fully-oop arrays are actually records;
because, they often have a variety of types .
. arrays are parameterized types,
and records can be parameterized too
. here's a syntax for allowing a record
to describe parts of itself the way arrays do:
reca(n.int).type: ( a.t1, b.t2, #(0..n).t3 );
x.reca(3)
-- now x = (a:..., b:..., 0:..., 1:..., 2:..., 3:... ).

{parameterized, variant} records

adda/type/{parameterized, variant} records:

4.15: adda/dstr/variant vs parameterized records:
. a parameterized type is not the same thing
as a variant record;
the parameter of a parameterized record type
works like a function, representing a set of subtypes;
eg, it might determine the max length of an array,
or the type of a list's items .
. the variant record, on the other hand
-- which is what is expressed by
.(x? #1: v.t1; #2: v.t2; #3: v.t3 #.)  --
is not requiring a parameter to express its discriminant;
the discriminant can be changed dynamically,
and must be changed in order to mirror
any changes in the way the variant is used .
. conversely, if the discriminant is changed,
then the current variant it represented must be erased,
as the new variant is initialized .

high-level uses of pointer and possessive

3.22: adda/dstr/high-level uses of pointer and possessive:
. both pointers (as seen in subdirectory syntax)
and possessives (as seen as component selection by structs)
can be seen as different ways to express the same thing;
but one way they express different things
is that ptr's don't imply ownership
as they often implement sharing .
. shouldn't adda use the {pointer, possessive} symbols
for the model views?
ie, ownerships can be impl'd with pointers,
but if the understood relation is ownership,
then the pointer should be written as a possessive mark .
that idea may be the same as this:
the important thing in design is to follow an interface .
3.31:
. indeed, this was really an empty debate,
since these operators do have different interfaces,
and it's the writer -- not the lang designer --
who has control of which relation to make structures with .

parameter blocks

1.20: adda/dstr/param'blocks:

. back when I was studying inside mac
-- before mac os X --
they had param'blocks:
huge records that would hold lots of options
so that when using services like window mgt
you didn't have long param' lists with every call .

. it would be even more convenient if
merely importing a subprogram would also
declare and implicitly apply a param'block for you .
. the translated code would have to include
a parameter -- the pointer to the param'block --
but user's code would not have to include that .

. param'blocks can be viewed as
caller-defined defaults
-- that's in contrast to the usual
subprogram-defined defaults
where if you don't specify an arg'
then the sub' provides one for you .

. param'blocks could also work like packages
in that name clashes could be avoided by
using the sub's name as owner of the global:
sub`global .

. another way to do this is ada`packaging:
have the sub' be a component of it's struct
where you can have
sub`[caller-defined default]`= [your pref's],
and then also do a call that uses that preference:
sub`fun(args) .

comparing array, record, function, and assoc'array

1.3: adda/dstr/comparing array, record, function, and assoc'array:

array vs function is storage:
. array is always stored as array
while a function can be
either associative array or formula .
. assoc'array is really a variable function .
. when taking a slice of each,
fun' keeps keys, while array re-keys;
eg,
doing an array slice from middle of an array
to replace an entire other array,
starts keys at destination's first key .
[. the diff is array's keys are address-oriented,
while fun is value oriented .]
. arrays have no formulae, and no param' modes
. {array, rec} literals look the same
but rec is associative:
a subslice retains associations .
. like arrays,
rec's can have slices:
r`{keys,,,} -> {r`compon's,,,}
r`(var) -> r's component whose key is a symbol returned by var
r`(,,,vars) -> r's component named by path returned keys
ie, the vars return a list of symbols that are
a pathname to a component in nested subrec's) .
. obj's in rec are ordered,
and a rec assignment is compatable if
their component types are compatable
(the rec'components may not be
stored as listed in rec,
but component assignments still work as if
that's the case ) .
. recs have fixed domain,
while arrays can vary in size (#first ...#last)
and functions are fully definable;
eg, a varying function (vs a const function)
allows slices which are lists of pairs;
. part of a varing function's attributes
includes the [currently defined domain];
you can traverse the [entire potential domain];
and, an undefined domain.point returns nil;
or, you can traverse the [currently defined domain],
which assures there will be no nil returns
(eg,
f(x) for x in f`dom ) .
. f`dom is a set that can be ordered with a pipe:
f`dom @ sort (-1) .

1.21: adda/dstr/function vs array:
. a function should be able to assign to subsets of domain
f(sA)`= '(formula);
array vs fun has no formula, and is not sparse;
Python`dictionaries are sparse, so they are functions
... -- this confuses impl vs concept:
array represents an obj' with multiple components
like a rec' or tuple except that
all but all components have the same type .
. functions are a set of tuples .