ways of referring to non-locals

7.28: adda/function/ways of referring to non-locals:
[8.8: intro:
. when namespaces are nested
such as when a program contains subprograms,
the usual situation is called shadowing
which means, for example, that if
subsub is within sub is within main,
and they each declare a symbol, x;
then each scope sees only its own x .
. if subsub wanted to see main's x,
it might specify a pathname;
eg, global/main/x .
. we might also require this for all globals
just to make it easy on the reader;
because if symbol y were not defined in subsub
yet subsub was using it,
then  we have to look in every superscope,
(sub, and main, in this example).
whereas, if we require pathnames for globals,
then the reader instantly knows the meaning of
global/main/sub/y .]

. instead of refering to a scope's ancestors
to reach globals,
we could use "(global) treated as root of fs
to reach non-locals .
. "(parent) is useful as a namespace root,
but if you're going to have a parent.keyword,
users will expect a grandparent as well
(gparent, ggparent, gggparent, etc) [8.8:
so that instead of writing global/main/sub/y
it can be compacted to gparent/y .]
...
. of ways to identify globals,
it was suggested that we could recognize
such roots as {global, parent, gparent, etc};
but in our case,
the global namespace will be static
(no symbols are added after compile time);
so that gives us an advantage
that will make it easier on the writers:
all they need to do is find
some unique subset of the url,
and then we can identify the full url
by doing a bottom-up search
comparing the leaf first . [8.8:
... however, chances are,
that is hardly reader-friendly;
if the name seems long, and it's used much,
then use renaming: ( x: gparent/x; ); 8.9:
nevertheless, we can have the compiler
use this system for helping both readers and writers,
by letting writers abbreviate, and then
expanding abbreviations to help readers .]

function graph editing

8.4: adde/function graph editing:

. how is audio graphing done?
how is the gui separated from the command processor?

. each unit of mouse movement
practically represents a pixel unit
which then represents a range of data points;
the first of those points can be chosen;
or if there is a sharp spike
then find the high and low
to include every point inclusive;
ie, graph a vertical line instead of a point .

. audio graphing is like strings of words,
but instead of the words differing in length,
they are all on their side for differing height .
. range selections result in a pair of numbers:
the {begin, end} of range,
which are then sent to the processor .
. if the range was possibly modified,
the editor then has to regraph that range .
8.28:
. the editor can handle this without knowing
the particulars of the audio graphing,
because it will have an interface for
generic function editing;
or rather,
the editor and every command processor
will all speak the system language:
the system's language describes
a mathematical function
as either a set of points or a formula
along with a type specification that includes
a domain and codomain;
with an optional subdomain and inverse operator .

function type's literal

3.30: mis.adda/dstr/function type's literal as @:
. just as #.t is the array type's literal,
the function should have something besides ()
because then how do you say function's type
symbolically rather than literally ?
isn't it tacky having manditory useless paren's?
. the @ is english's symbol for function application,
so then @.t could be function type's literal .
then to define the arg type symbolically,
say rec.type: (v.t, ...),
you have @rec.t or #rec.t .
. but then you'd expect
f@x
whereas the english expectation from email syntax is
x@f .

the number-mark as subscript

3.29: adda/dstr/syntax/# as subscript:
. noticing #().t -- the array type's literal --
may not sit well with the idea that
the #-symbol would be interchangeable with
the subscripting of what comes after the # .
. to be consistent with math,
array typing would have to be described
the same way that functions are:
A: i`type -> return`type .
3.31:
. arrays differ from functions in that
a function includes as part of its value
the domain set that is addressing its codomain .
. arrays by contrast, are a list of values,
and the addressing scheme is associated
like so:
. I could have A and B both assigned
to the same value: (1,2,3);
and A could be type #{a,b,c}.n,
while B could be type #{x,y,z}.n;
ie, their values are the same type;
whereas, 2 such functions would not
have the same value: one is { a:1, b:2, c:3},
while the other's value is { x:1, y:2, z:3} .

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 .