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} .

rethinking aggregates

4.28: adda/dstr/agg's in literal mode:

. the expression (www.the.com)
is same as (www#the#com)
except that with (www.the.com)
you know the component selectors are literals,
whereas with (www#the#com),
(the) and (com) are likely variables .

. a record field works like a based pointer,
just as an array index does,
except that the distance between components
is not constant .
. records (and even arrays)
can have their components reached literally
via something other than (#)
and the example of (www.the.com)
suggests the dot should be reused for that .
. this way it works like numbers, too:
they have 2 literal parts {frac, int}
connected by a dot
-- a model even more common than url's .
. the use of dots is well-understood,
it looks neat,
and it's easy to reach on the kybd
-- much more so than (`)
(the possessive operator).

. how can reuse of the dot then avoid
confusion with types decl's?
-- eg, A.1 vs A.anArrayType --
it requires that the entire type`name`space
is barred from being reused as a component`name;
ie, if a name already stands for a type,
it can't be used as the name for any component .
. that would be easy if there was a rule like
(type`names must be capitalized),
-- as it is in math --
but most would rather write .int than .Z .

4.29: web.adda/terminology/based pointer:
. what is term for what I like to call
offset pointer? based pointer

4.28: adda/dstr/array-record equivalence:

. wondering why records and arrays
should vary their syntax from each other:
an array is simply a record where
all components are the same type,
yet array#field
vs record`field ?
. but, in database design -- a fundamental --
there's the idea of the multiples (arrays)
vs the units (records);
just as both fractions and integers
may have the same use of digits
but nevertheless very different roles .

. look at the entire lifetime of their use,
including decl's, and the other use of (`),
is it complementary ?

. t.type: <. `f, `+, + .>
; a#.t -- a#.<. `f, `+, + .>
; r.(x.t, y.s) --. a record .
; p/.(x.t, y.s) --. pointer to same .
; b.t --. declares { b`f, b`+, b+... }.
; a#1, r#x, p/x, b`x .

. where did I get the idea that
the operator(`) could be reserved for
self-modifiers?
. can't an aggregate component be a function?
then it works just like in a type def':
when a function is part of an agg'
it has access to every other component of that agg' .
b`++, b#f(x)
. the agg' declarations themselves
don't have hidden locals;
but, if a type def includes an agg' def,
then it defines an agg whose
component functions could be accessing hidden locals .

4.19: adda/cstr/rom-address-mode params:
. [pass by ref] (aka address-mode)
is often more efficient
but in some lang's [pass by copy] (aka value-mode)
is the only sure way to know inputs aren't modified .
. the interface should make clear to the compiler
whether a certain operation is modifying or not;
only then can the compiler be efficiently helpful .
4.20:
functionals have an interface like this:
f(x), f(l,r),
whereas mutators appear like this:
`f, `++, `*(x), `+(x) .

more 2nd-thoughts for use of dot notation:

4.22: todo.adda/type/filter-class generic types:
. studying c++'s generic types, eg atomic:
http://bartoszmilewski.wordpress.com/2008/12/01/c-atomics-and-memory-ordering/
adda's syntax for the parameterized type would be:
atomic(your.type).type: ...
. a generic is normally used like this:
i.atomic(int)
-- i is a version of atomic.type --
but why not i.atomic.int ?
atomic is an important example
of a special class of generic type
in which it offers as output
the same type as was input
providing a modified but nevertheless compatible semantics .
. they would be modeled after arrays,
a#.int
which has so far escaped definition
due to its being a primitive type .
todo:
review how #(x).t, (x).t, /.t
are similar and different,
and how there can be a syntax
for defining a generic array type
had the system not already done it .
. review the named pointer theory
since it has the most in common with that .

4.20: adda/type/more use of multiple dots:
. here's another place where double typing is needed:
msg.Channel.String;
. the var"msg represents a channel
through which is passed obj's of type"string .
. it's like the array, msg#.String,
being a sort of container of strings
but numerous in the time domain
vs space domain .

other lexical change ideas:

4.22: adda/operators/ancestor scope:
. my current system defines a local as
a symbol that includes a type specification;
but, aren't there times when you'd like to
rename or otherwise access an external
as something like:
"( give me the x from however many levels above
that has this particular type) ?
. one way to do that is with a new symbol:
just as the current system allows
../x.t to mean parent scope's object of type x.t,
.../x.t could mean the same but
for any ancestor scope .

4.20: adda/numeric base syntax:
. hex could folow both dimensional syntax and subscript syntax
by treating (space)#(integer) as dimension;
eg, 7FFF #16 or (ART)#32 .
-- using either the space or the parenthetical
is needed to avoid confusing A#16
with the 16th item an array named A .
. an array would allow spacing the other way:
A# 16 -- rather than:
A #16 .

4.12: adda/cstr/pointer arithmetic:
. my first idea for distinguishing between
arithmetic on a pointer vs their targets
was to use an explicit dereference operator;
but ambiguity happens rarely
-- only when the target is a numeric type
and the operation is one that applies to pointers --
so, another idea is to use attribute syntax
to indicate when the operation is on the address .
. my first idea was ptr`addr + i,
but `addr should take the addr of the symbol;
my subsequent idea was to use array notation,
since that is what pointer arithmetic is doing:
ptr#i = ptr + i .

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 .