object copy & paste

7.14: adde/object copy & paste:

. the typical copy & paste
is a char-string operation;
whereas, an object selection
is operating over etrees (expression trees)
which are tree nodes with pointers into
dictionaries of symbols (symbol tables).
. there can be more than one symbol table;
because, a dictionary can include procedures,
and procedure definitions can have local dictionaries;
hence, a single etree can be within
the scope of multiple dictionaries
represented by stacks of local symbol tables .

. a copy becomes a module
meaning it needs its own copy of
any local symbol tables;
however, the cost of copying
depends on the destination:
if the paste location is within the source's scope
it shares all the same symbol tables .
. when some symbol tables are
not shared between source and destination
those tables must be copied;
and, affected etree nodes adjusted
to point into the new tables .

. when an arbitrary substring is selected
it can be representing fractions of etrees,
eg, given a+b+c, a selection can include
all of term-b and partials of terms {a,c} .

. there may be parts of the given language where
partial terms don't have the same meaning;
ie, there would be nothing but a
char-string translation of the object selection .
. in any case,
the quickest, most general way to define a selection
is to get links to the entire chain of symbol tables;
and, copy the entire subtree that contains
all the fragments of the selection;
then include a descriptor that shows
where the selection is beginning and ending .

. when would you want fragments and still want
the etree object rather than a char string?
for orthogonality,
we have to provide for the possibility
that one of adde's plug-in app's
can find some use for such a selection;
ie, in many cases of user interaction
the selection is for a function other than
cut or copy .

7.15:
. when designing the pointer that is
going from etree nodes into symbol tables,
there must be an efficient coding,
and it should support efficient copying
even when it involves context changes .

. both the source and destination of a copy
have scope paths:
if the scope paths aren't the same
we have to identify any scopes not shared
and copy their symbol tables
for merging with the destination .
if this is a cut instead of a copy,
there are fewer choices,
since the destination space is smaller .

. a complication of multiple nestings of scope
is the orphaned symbol from ancestor scopes:
these imply some sort of communication with
a context which no longer exists .
. we have to remind the user
that the orphan's place in the destination
may need special attention:
should it be added to the new parent scope,
or some higher scope ?
. the default location would be relative height,
ie, the same number of scopes up the path
as it was in the source location .
. in any case, we have to assist the user
in keeping track of these orphan relocations,
and make sure that all affected contexts
are adjusted to create a sensible communication
such that, the role of the source ancestor
is now provided by the new context's procedure .