12.28: adde/per-file dialect preference directive:
. when opening another author's strange dialect,
[@] adda/pre-processor/per-file dialect preference directive:
the editor auto-translates to your dialect .
. and when you name an object,
the editor asks how you came up with that name,
so that translators across country`languages
can have some clues for a good native alternative .
2011-12-31
listable column view & tiled work trays
12.26: co.self/dream/adde/listable column view & tiled work trays:
. there are fixed layers for levels of the fs:
file, 3..5 folders levels for various intentions
[just like the biology has {species, genus, phylum, etc}]
. you see things arranged as columns,
[like mac`finder's column view,
but combined with the mac`finder [hierarchical] list view,
where more than one branch of the folder tree can be expanded]
then how do you arrange the rows to
keep files separate from folder systems ?
. have trays on the desktop,
corresponding to each of the columns;
they are easy for the user to rearrange, but they stay tiled;
and they have some way of stacking like mac has;
what way is that ? uh .
--[. I had done stim's just before bed;
because I was too stressed, and didn't want to be bored
in case there was insomnia;
I think I was half awake for this;
but it was dream-like in the sense of
the thought process being more concerned with
images of the ideas,
and not too quick to discount an idea as trivial or useless;
it does remind me that you can't really know
what users will find useless,
so the primary feature should be making it easy for
users themselves to design desktop behaviors .]
. there are fixed layers for levels of the fs:
file, 3..5 folders levels for various intentions
[just like the biology has {species, genus, phylum, etc}]
. you see things arranged as columns,
[like mac`finder's column view,
but combined with the mac`finder [hierarchical] list view,
where more than one branch of the folder tree can be expanded]
then how do you arrange the rows to
keep files separate from folder systems ?
. have trays on the desktop,
corresponding to each of the columns;
they are easy for the user to rearrange, but they stay tiled;
and they have some way of stacking like mac has;
what way is that ? uh .
--[. I had done stim's just before bed;
because I was too stressed, and didn't want to be bored
in case there was insomnia;
I think I was half awake for this;
but it was dream-like in the sense of
the thought process being more concerned with
images of the ideas,
and not too quick to discount an idea as trivial or useless;
it does remind me that you can't really know
what users will find useless,
so the primary feature should be making it easy for
users themselves to design desktop behaviors .]
encryption with shifting code
12.22: adde/encryption with shifting code:
. you have sections prefixed with the lang id
and the lang id is encrypted too .
how? if the lang code is not randomized or implicit
(eg, by a hash of the section's 1st words;
say, along with some other rule)
then opponents could work on common code sections
to see which words are most freequently used .
[and with implicit lang code, imagine that every word was encoded differently
so a word is in a file giving it an nth word location
and for each location's code there are 2 maps:
the word map: words -> code;
the map map: word location -> word map index .
. so for each word at location L,
my.word.map = [array of maps](map.map(L));
code = my.word.map (word) .]
. you have sections prefixed with the lang id
and the lang id is encrypted too .
how? if the lang code is not randomized or implicit
(eg, by a hash of the section's 1st words;
say, along with some other rule)
then opponents could work on common code sections
to see which words are most freequently used .
[and with implicit lang code, imagine that every word was encoded differently
so a word is in a file giving it an nth word location
and for each location's code there are 2 maps:
the word map: words -> code;
the map map: word location -> word map index .
. so for each word at location L,
my.word.map = [array of maps](map.map(L));
code = my.word.map (word) .]
taming the arrogant dialog
12.5: adde/gui/taming the arrogant dialog:
. one reason some dialogs will block any other actions
is to not lose your selection
or anything you've already input to the dialog .
. suppose the dialog were a separate window
and the selection in your document window changes,
then it needs to check selection;
and, if it changed, the user is asked
"(do you want to resume it?);
if the doc is modified, user is asked:
"(does new selection still fit your intention
for this old dialog?).
. sometimes the specific content of the original selection
will have determined the dialog type
(this is like a context menu selection by you,
only the app is doing it implicitely;
eg, if the selection contains both text and graphics,
then choosing style from the menu
should bring up dialogs for both text and graphics).
. if the document or the selection has changed,
then the dialog typing should be redone .
. if the dialog must be changed,
then the app must return the data by
logging* the parameter values provided by user
or also apply those changes to a
subsequent use of the dialog .
*: ( the entire user session is logged,
so that user's can know in writing what they did
that had the given effect; they can also use this writing
as part of developing scripts to automate their chores).
history stack traversal:
. it could just store modifications with the dialog,
and have a browser control with a back button
for earlier dialog fillings .
(warning:
. that works only in a protected acct with one user
otherwise that is a new behavior that could get very rude )
. this is a very important generalization:
html gui's can mean more service not less .
. one reason some dialogs will block any other actions
is to not lose your selection
or anything you've already input to the dialog .
. suppose the dialog were a separate window
and the selection in your document window changes,
then it needs to check selection;
and, if it changed, the user is asked
"(do you want to resume it?);
if the doc is modified, user is asked:
"(does new selection still fit your intention
for this old dialog?).
. sometimes the specific content of the original selection
will have determined the dialog type
(this is like a context menu selection by you,
only the app is doing it implicitely;
eg, if the selection contains both text and graphics,
then choosing style from the menu
should bring up dialogs for both text and graphics).
. if the document or the selection has changed,
then the dialog typing should be redone .
. if the dialog must be changed,
then the app must return the data by
logging* the parameter values provided by user
or also apply those changes to a
subsequent use of the dialog .
*: ( the entire user session is logged,
so that user's can know in writing what they did
that had the given effect; they can also use this writing
as part of developing scripts to automate their chores).
history stack traversal:
. it could just store modifications with the dialog,
and have a browser control with a back button
for earlier dialog fillings .
(warning:
. that works only in a protected acct with one user
otherwise that is a new behavior that could get very rude )
. this is a very important generalization:
html gui's can mean more service not less .
dual document view for speedy use of read-only
12.5: adde/gui/dual document view for speedy use of read-only:
. in order to be quick, the typical help system is read-only;
but friendly would be quick and annotatable .
. an editor can be made very lightweight
if it does only small chunks of simple text;
summary:
. this is possible by a windowing system that is
combining 2 documents:
the readonly panes load quickly despite being large;
the mutable panes load quickly because they are small .
. when you ok the pane, it saves that pane as a temp' file .
. deleting part of a readonly pane simply redraws the pane
without the part you deleted .
. after your annotation session,
it will merge results in the background .
idea#1:
. the annotation window is attached to the side
at a point that starts at finding current wrapped line
where the anchor phrase is found .
. finally, in the background,
the edits are merged with the doc .
idea#2:
. another view of a faster edit system
is that old text is never modified,
it is simply interleaved with panes of new text,
deletions have their before&after's
presented in the same read-only pane,
but the drawing is simply skipping the deleted range;
this may seem like a complication,
but no more so than having to
draw segments in separate panes .
. if the text is not word wrapped, (has frequent newlines)
then it should do a heuristic about whether
the after-piece should be on a new line
or the same line with the before-piece .
. for transitioning from rom text to mutable text,
there should be separate panes
to speed up the layout engine .
. within a read-only doc, after making selection,
you can do 3 things:
add your comment { above, below} it,
or replace it .
. in order to be quick, the typical help system is read-only;
but friendly would be quick and annotatable .
. an editor can be made very lightweight
if it does only small chunks of simple text;
summary:
. this is possible by a windowing system that is
combining 2 documents:
the readonly panes load quickly despite being large;
the mutable panes load quickly because they are small .
. when you ok the pane, it saves that pane as a temp' file .
. deleting part of a readonly pane simply redraws the pane
without the part you deleted .
. after your annotation session,
it will merge results in the background .
idea#1:
. the annotation window is attached to the side
at a point that starts at finding current wrapped line
where the anchor phrase is found .
. finally, in the background,
the edits are merged with the doc .
idea#2:
. another view of a faster edit system
is that old text is never modified,
it is simply interleaved with panes of new text,
deletions have their before&after's
presented in the same read-only pane,
but the drawing is simply skipping the deleted range;
this may seem like a complication,
but no more so than having to
draw segments in separate panes .
. if the text is not word wrapped, (has frequent newlines)
then it should do a heuristic about whether
the after-piece should be on a new line
or the same line with the before-piece .
. for transitioning from rom text to mutable text,
there should be separate panes
to speed up the layout engine .
. within a read-only doc, after making selection,
you can do 3 things:
add your comment { above, below} it,
or replace it .
1st-class subfile renaming
12.4: news.adde/fs/1st-class subfile renaming:
. Brandon Casey June 20th, 2007,
mentioned the idea of 1st-class subfile renamingwhich is a version tracking system that recognizes
when file modifications consist of subfile moves:
"( I split the file into two files in my repo.
File is modified in source repo.
I retrieve changes from source repo.
Will changes be correctly applied to
relevant sections in the two new files?
).
. Casey was responding to an article about
www.markshuttleworth.com/archives/123
tracking renames as a first class operation,
which I would call 1st-class file renaming;
so, Casey's idea is 1st-class subfile renaming .
. the minimalist style of version tracking
is to wait for a commit,
and then respond to modifications:
# directory changes are seen as
file {adds, deletes};
# file modifications are recorded with a
line-oriented diff' file .
. in previous notes on subfiles,
the system recognizes structure within files:
eg, html files have header tags, H1, H2, ... H6;
and, each represents a hierarchical subfile,
as do paragraphs, divisions, and other enclosing tags .
. the file system is just a tree of pointers;
likewise, this tree extends to subfiles;
and files become pointers to sections of text
which are actually in a database
named by their creation date & author
(plus an optional serial# for when
several subfiles have the same create date;
for example when a file is modified by
having some paragraphs inserted,
the paragraphs' create dates are considered to be
at the file's modified time .
).
. the branch copies db names
and each simultanious branch belings to one author;
so, that author'name must be part of a subfile's db name .
1st-class subfile renaming:
. the folder-subfile system is a tree:
a collection of nodes
(visualized as forks for representing enclosures )
and edges
(visualized as branches for representing
the things they contained by an enclosure ).
. a folder-representing node is thus remembering
# the name of the folder,
# edges to all nodes the folder contains;
likewise, a file-representing node has the file's name,
and the edges to subfiles it contains;
but, a paragraph-representing node
has a position number in place of a name
( so, when a paragraph gets inserted,
that bumps all the position numbers of paragraphs below
(within that subfile not the entire file)).
. when version-tracking for subfiles,
the nodes that were revised
are replaced with version-representing nodes
(version node) with edges to
both the replaced node,
and to the new node created by the revision;
in summary,
modified nodes are presented as a menu
of version choices;
eg, a folder-move creates version nodes twice:
once at both the source and destination nodes .
12.5:
. what if the version node is not the smartest
way to see changes?
the friendliest way is to show the various views:
# toc's for each version:
when there a high use of 2 views,
make sure both are fully built (not defined as a script)
the db will then be like a book with 2 toc's (table of contents).
# index:
. search of index finds every instance
showing you the pathnames,
and grouping together occurrences of
1 object is in several locations across versions .
# glossary:
. the place for histories of how a name has been used,
and why it has been changed from and to other names .
. this would include the human view of
why there systematic renames in certain versions .
. Brandon Casey June 20th, 2007,
mentioned the idea of 1st-class subfile renamingwhich is a version tracking system that recognizes
when file modifications consist of subfile moves:
"( I split the file into two files in my repo.
File is modified in source repo.
I retrieve changes from source repo.
Will changes be correctly applied to
relevant sections in the two new files?
).
. Casey was responding to an article about
www.markshuttleworth.com/archives/123
tracking renames as a first class operation,
which I would call 1st-class file renaming;
so, Casey's idea is 1st-class subfile renaming .
. the minimalist style of version tracking
is to wait for a commit,
and then respond to modifications:
# directory changes are seen as
file {adds, deletes};
# file modifications are recorded with a
line-oriented diff' file .
. in previous notes on subfiles,
the system recognizes structure within files:
eg, html files have header tags, H1, H2, ... H6;
and, each represents a hierarchical subfile,
as do paragraphs, divisions, and other enclosing tags .
. the file system is just a tree of pointers;
likewise, this tree extends to subfiles;
and files become pointers to sections of text
which are actually in a database
named by their creation date & author
(plus an optional serial# for when
several subfiles have the same create date;
for example when a file is modified by
having some paragraphs inserted,
the paragraphs' create dates are considered to be
at the file's modified time .
).
. the branch copies db names
and each simultanious branch belings to one author;
so, that author'name must be part of a subfile's db name .
1st-class subfile renaming:
. the folder-subfile system is a tree:
a collection of nodes
(visualized as forks for representing enclosures )
and edges
(visualized as branches for representing
the things they contained by an enclosure ).
. a folder-representing node is thus remembering
# the name of the folder,
# edges to all nodes the folder contains;
likewise, a file-representing node has the file's name,
and the edges to subfiles it contains;
but, a paragraph-representing node
has a position number in place of a name
( so, when a paragraph gets inserted,
that bumps all the position numbers of paragraphs below
(within that subfile not the entire file)).
. when version-tracking for subfiles,
the nodes that were revised
are replaced with version-representing nodes
(version node) with edges to
both the replaced node,
and to the new node created by the revision;
in summary,
modified nodes are presented as a menu
of version choices;
eg, a folder-move creates version nodes twice:
once at both the source and destination nodes .
12.5:
. what if the version node is not the smartest
way to see changes?
the friendliest way is to show the various views:
# toc's for each version:
when there a high use of 2 views,
make sure both are fully built (not defined as a script)
the db will then be like a book with 2 toc's (table of contents).
# index:
. search of index finds every instance
showing you the pathnames,
and grouping together occurrences of
1 object is in several locations across versions .
# glossary:
. the place for histories of how a name has been used,
and why it has been changed from and to other names .
. this would include the human view of
why there systematic renames in certain versions .
optimizing timemachine
12.4: adde/fs/optimizing timemachine:
. mac's timemachine can prevent corruptions;
adde's version of that could additionally preserve memory
(and thereby store more changes)
by analyzing how things change,
and asking the user why something got deleted .
--
. the inspiration for this idea was that
my data had be corrupted by a fat32 sd card error;
and although timemachine did save me,
all I really needed was
some automatic analyst to notice strange behavior:
the user fills up log entries,
but here one has been deleted ?
a folder had many files but is now null ?
12.5:
. the prior, simpler idea that helps as much
is to keep all user contributions in a read-only db,
and saving memory by automatic duplicate removal
(a file can saved as a script such as:
include these 3 subfiles,
and then replace phrase x with y ).
. adde questions the user upon each deletion:
why is this deleted?
# somewhere else: deleted when verified;
# not yours : did you want to log this? source?
# duplication:
adde has automatic duplicate removal .
. mac's timemachine can prevent corruptions;
adde's version of that could additionally preserve memory
(and thereby store more changes)
by analyzing how things change,
and asking the user why something got deleted .
--
. the inspiration for this idea was that
my data had be corrupted by a fat32 sd card error;
and although timemachine did save me,
all I really needed was
some automatic analyst to notice strange behavior:
the user fills up log entries,
but here one has been deleted ?
a folder had many files but is now null ?
12.5:
. the prior, simpler idea that helps as much
is to keep all user contributions in a read-only db,
and saving memory by automatic duplicate removal
(a file can saved as a script such as:
include these 3 subfiles,
and then replace phrase x with y ).
. adde questions the user upon each deletion:
why is this deleted?
# somewhere else: deleted when verified;
# not yours : did you want to log this? source?
# duplication:
adde has automatic duplicate removal .
transaction-based software configuration mgt system
12.4: news.adde/transaction-based software configuration management system:
Wheeler`Software Configuration Management (SCM) Security
http://aegis.sourceforge.net/propaganda/security.html
Once authenticated, users do not have write access to the
meta-data or history files of any change set.
The vast majority of "hooks" are in files controlled by Aegis' process;
to maliciously change one requires a conspiracy of
developer, reviewer and integrator.
Aegis is a transaction-based software configuration management system.
pdf"proj change supervisor
http://aegis.sourceforge.net/auug93.pdf
pd"only for software?
http://aegis.sourceforge.net/auug96.pdf
It provides a framework within which a team of developers
may work on many changes to a program independently,
and Aegis coordinates integrating these changes
back into the master source of the program,
with as little disruption as possible.
. more from same author: peter miller .
[@] news,web.adds/openware/peter miller
--
. that reminded me how my logging is helped by a 2-step process:
. one process just adds stuff,
and then another (in a sharp state)
is doing reorganizations, and deletions .
. adde could help by enforcing this:
# the editor-mode user makes only requests
that are virtually filled;
# the reviewer-mode user can fill requests
that do the work, and save the space taken by
holding both the before and after states .
Wheeler`Software Configuration Management (SCM) Security
http://aegis.sourceforge.net/propaganda/security.html
Once authenticated, users do not have write access to the
meta-data or history files of any change set.
The vast majority of "hooks" are in files controlled by Aegis' process;
to maliciously change one requires a conspiracy of
developer, reviewer and integrator.
Aegis is a transaction-based software configuration management system.
pdf"proj change supervisor
http://aegis.sourceforge.net/auug93.pdf
pd"only for software?
http://aegis.sourceforge.net/auug96.pdf
It provides a framework within which a team of developers
may work on many changes to a program independently,
and Aegis coordinates integrating these changes
back into the master source of the program,
with as little disruption as possible.
. more from same author: peter miller .
[@] news,web.adds/openware/peter miller
--
. that reminded me how my logging is helped by a 2-step process:
. one process just adds stuff,
and then another (in a sharp state)
is doing reorganizations, and deletions .
. adde could help by enforcing this:
# the editor-mode user makes only requests
that are virtually filled;
# the reviewer-mode user can fill requests
that do the work, and save the space taken by
holding both the before and after states .
rule of contract vs right to perfect memory
12.1: adde/rule of contract vs right to perfect memory:
. the rule of contract states that the most important law
is the games people agree to play by;
eg, whether or not close-source is right,
if the user and producer can both agree to it,
then it should be supported .
. although the rule of contract is important,
it often concerns content use restrictions
that conflict with an even more important right:
pursuit of a perfect mind with a perfect memory;
because, being able to remember every experience
entails copying content for replay to yourself;
but, copying content under current systems,
always implies the ability to distribute it to others .
. to facilitate the right to perfect memory,
and system must be able to provide replay
only to those who already seen the playback .
. it must have encrypted files for such memories,
which the own can't unencrypt .
. this would also require a system for insuring
that there was no copying processes
between crypt and display .
. the openware community has had concerns about
something called a trusted platform chip
that it would reduce control ?
. can't recall the details, but we can avoid that;
simply imagine a system where it's like it is now,
but there's a overlayed subsytem
where if encryption is being displayed
only at this time is no other process
allowed to scrape the video ram .
. the rule of contract states that the most important law
is the games people agree to play by;
eg, whether or not close-source is right,
if the user and producer can both agree to it,
then it should be supported .
. although the rule of contract is important,
it often concerns content use restrictions
that conflict with an even more important right:
pursuit of a perfect mind with a perfect memory;
because, being able to remember every experience
entails copying content for replay to yourself;
but, copying content under current systems,
always implies the ability to distribute it to others .
. to facilitate the right to perfect memory,
and system must be able to provide replay
only to those who already seen the playback .
. it must have encrypted files for such memories,
which the own can't unencrypt .
. this would also require a system for insuring
that there was no copying processes
between crypt and display .
. the openware community has had concerns about
something called a trusted platform chip
that it would reduce control ?
. can't recall the details, but we can avoid that;
simply imagine a system where it's like it is now,
but there's a overlayed subsytem
where if encryption is being displayed
only at this time is no other process
allowed to scrape the video ram .
short pointer
12.22: adda/type/short pointer:
pos: kiss:
. build the obvious system first;
don't worry about having to
rebuild from scratch in order to merge an optimization;
it's important for testing that there are
simple, trustworthy substitutes .
summary:
. shorter pointers could save a lot of space;
in c, pointers may be 4-bytes long
in order to address any place on the machine .
. addresses can be byte-sized only if needing
less than 256 addresses; for instance,
an array(1..256)of word can hold 256 tree nodes;
and, each node has 2 bytes,
each of which can point to any place in that array .
. a larger tree would use word-sized pointers,
which means the nodes are 4bytes long
(2pointers * 2bytes).
. the byte- and word-sized addresses
use an array index to do the pointing;
and, are collectively called short pointers;
any use of a short pointer implies a reference to
some particular array;
eg, the root of a tree would be a descriptor
which identifies the tree as using short pointers
and then provides a link to the array being referred to .
. a tree descriptor would also include
a separate array for data;
because, arrays need to contain just one type
(unless its items all have bulky type tags);
and, while all internal tree nodes
are of type (ptr, ptr),
the leaf nodes contain data of varying sizes and types;
so, the data array might contain system pointers;
or, it could use a heap system,
where the pointer refers to several items:
the first item contains a size field
which indicates how many subsequent items
belong to this datum .
. large trees (uses word-pointers)
may contain small trees (uses byte-pointers);
any subtree of a large tree containing less than 256 nodes
could be repacked as a pointer to small tree .
. as the list processor goes into a tree,
it is always keeping the current base addresses
for both the large tree and any small tree .
. a large tree is chosen over a small tree type
not only when it will always be large,
but also when it is likely to grow .
. often it will never approach its max size;
therefore the array being used for the
internal nodes of a large tree
should have a growable size to conserve space .
. one way of being growable is to be
an array of pointers to segments:
eg, suppose the segment is 10 units;
then for item# 78,
follow the 7th pointer to a segment,
and use the 8th item on that segment .
. in practice,
the segments likely should be the size of small trees
( 256 nodes * 2pointers * 1 byte).
. while the large tree is indexing the seg'd array,
a small subtree could index a segment therein .
[12.23:
. since the short pointers of a large tree are
pointing at a seg' pointer,
seg's could vary in type, and be type-tagged,
that way the large tree can point directly at a small tree
without having to redirect to a data array .
. the large tree is an array of
( pointer to seg
, enum"seg nodes are {word, long}
)].
. both the large tree (word-pointers)
and the small tree (byte-pointers)
can have a bit per word to indicate
whether they point to tree or data .
. word-sized pointers use their sign bit for indicating
whether they point to tree or data;
byte-sized pointers exist in pairs on word-sized nodes,
and a byte is too small to sacrifice a bit,
so we'll divide the segment in half;*
if the positive side is used (a byte in 0..127)
that item is an internal node;
else (a byte in 128..255) the item is a leaf node .
*(conveniently, no matter what the shape of a tree,
the number of internal and leaf nodes is nearly the same:
#leaf = #internal + 1 )
A binary tree with N internal nodes has exactly N+1 external (leaf) nodes
Proof: by induction
Base case:
a binary tree with 0 internal nodes has exactly 1 external (leaf) node (root)
Induction step:
. assume a binary tree with m internal nodes
has exactly m+1 external (leaf) nodes
A binary tree with N internal nodes is made up of:
A root (internal node)
A left binary trees with k internal nodes
A right binary trees with (N - 1 - k) internal nodes
According to the induction assumption:
The left binary trees with k internal nodes has exactly
k+1 external nodes
The right binary trees with (N - 1 - k) internal nodes
has exactly (N - k) external nodes
So the total number of external nodes
in a binary tree with N internal nodes is:
k+1 + (N - k) = (N + 1 ) external nodes .
notes:
binary operation polymorphism:
. tree polymorphism works the same way numbers do:
if a biop has to deal with (byte, word),
it converts byte to word for the (word, word) vm;
ie, it makes a copy of the tree but with new pointer types .
. by making small arrays part of larger ones
you would be doing more of your own mem mgt
instead of using c mem mgt
which expects you to de/allocate in stack order;
use c mem mgt for arrays whenever possible;
but use small arrays for tree nodes
to keep tree-pointer size down .
. the segs of a seg'd array
can either come from malloc,
or be pointers into a reserve array
where you're doing your own mem mgt .
. the small tree needs arrays of size = word*256
-- that may be the right size for units used by seg'd arrays .
. of the pointer and its target,
which should contain needed subtype tags?
if the target contains the id,
then there is efficient aliasing;
but in some targets there would be bloat
because targets like system pointers need the whole obj,
and can't spare a few bits for type tagging,
so then an additional array of byte for tagging is needed .
pos: kiss:
. build the obvious system first;
don't worry about having to
rebuild from scratch in order to merge an optimization;
it's important for testing that there are
simple, trustworthy substitutes .
summary:
. shorter pointers could save a lot of space;
in c, pointers may be 4-bytes long
in order to address any place on the machine .
. addresses can be byte-sized only if needing
less than 256 addresses; for instance,
an array(1..256)of word can hold 256 tree nodes;
and, each node has 2 bytes,
each of which can point to any place in that array .
. a larger tree would use word-sized pointers,
which means the nodes are 4bytes long
(2pointers * 2bytes).
. the byte- and word-sized addresses
use an array index to do the pointing;
and, are collectively called short pointers;
any use of a short pointer implies a reference to
some particular array;
eg, the root of a tree would be a descriptor
which identifies the tree as using short pointers
and then provides a link to the array being referred to .
. a tree descriptor would also include
a separate array for data;
because, arrays need to contain just one type
(unless its items all have bulky type tags);
and, while all internal tree nodes
are of type (ptr, ptr),
the leaf nodes contain data of varying sizes and types;
so, the data array might contain system pointers;
or, it could use a heap system,
where the pointer refers to several items:
the first item contains a size field
which indicates how many subsequent items
belong to this datum .
. large trees (uses word-pointers)
may contain small trees (uses byte-pointers);
any subtree of a large tree containing less than 256 nodes
could be repacked as a pointer to small tree .
. as the list processor goes into a tree,
it is always keeping the current base addresses
for both the large tree and any small tree .
. a large tree is chosen over a small tree type
not only when it will always be large,
but also when it is likely to grow .
. often it will never approach its max size;
therefore the array being used for the
internal nodes of a large tree
should have a growable size to conserve space .
. one way of being growable is to be
an array of pointers to segments:
eg, suppose the segment is 10 units;
then for item# 78,
follow the 7th pointer to a segment,
and use the 8th item on that segment .
. in practice,
the segments likely should be the size of small trees
( 256 nodes * 2pointers * 1 byte).
. while the large tree is indexing the seg'd array,
a small subtree could index a segment therein .
[12.23:
. since the short pointers of a large tree are
pointing at a seg' pointer,
seg's could vary in type, and be type-tagged,
that way the large tree can point directly at a small tree
without having to redirect to a data array .
. the large tree is an array of
( pointer to seg
, enum"seg nodes are {word, long}
)].
. both the large tree (word-pointers)
and the small tree (byte-pointers)
can have a bit per word to indicate
whether they point to tree or data .
. word-sized pointers use their sign bit for indicating
whether they point to tree or data;
byte-sized pointers exist in pairs on word-sized nodes,
and a byte is too small to sacrifice a bit,
so we'll divide the segment in half;*
if the positive side is used (a byte in 0..127)
that item is an internal node;
else (a byte in 128..255) the item is a leaf node .
*(conveniently, no matter what the shape of a tree,
the number of internal and leaf nodes is nearly the same:
#leaf = #internal + 1 )
A binary tree with N internal nodes has exactly N+1 external (leaf) nodes
Proof: by induction
Base case:
a binary tree with 0 internal nodes has exactly 1 external (leaf) node (root)
Induction step:
. assume a binary tree with m internal nodes
has exactly m+1 external (leaf) nodes
A binary tree with N internal nodes is made up of:
A root (internal node)
A left binary trees with k internal nodes
A right binary trees with (N - 1 - k) internal nodes
According to the induction assumption:
The left binary trees with k internal nodes has exactly
k+1 external nodes
The right binary trees with (N - 1 - k) internal nodes
has exactly (N - k) external nodes
So the total number of external nodes
in a binary tree with N internal nodes is:
k+1 + (N - k) = (N + 1 ) external nodes .
notes:
binary operation polymorphism:
. tree polymorphism works the same way numbers do:
if a biop has to deal with (byte, word),
it converts byte to word for the (word, word) vm;
ie, it makes a copy of the tree but with new pointer types .
. by making small arrays part of larger ones
you would be doing more of your own mem mgt
instead of using c mem mgt
which expects you to de/allocate in stack order;
use c mem mgt for arrays whenever possible;
but use small arrays for tree nodes
to keep tree-pointer size down .
. the segs of a seg'd array
can either come from malloc,
or be pointers into a reserve array
where you're doing your own mem mgt .
. the small tree needs arrays of size = word*256
-- that may be the right size for units used by seg'd arrays .
. of the pointer and its target,
which should contain needed subtype tags?
if the target contains the id,
then there is efficient aliasing;
but in some targets there would be bloat
because targets like system pointers need the whole obj,
and can't spare a few bits for type tagging,
so then an additional array of byte for tagging is needed .
abi - c's definition of abi differs
12.22: mis.adda/abi/c's definition of abi differs:
. in c culture, the abi(app binary interface)
has meant an interface between apps and
binary library units vs source libraries .
. my definition of ABI has been a system of
cross-app communication using a binary language
rather than a exchanging text like unix .
. for instance, see standard ABIs motivation:
"( 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 ).
. in c culture, the abi(app binary interface)
has meant an interface between apps and
binary library units vs source libraries .
. my definition of ABI has been a system of
cross-app communication using a binary language
rather than a exchanging text like unix .
. for instance, see standard ABIs motivation:
"( 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 ).
capitalization rules are out
12.14: pos.adda/capitalization rules are out:
. did you notice the capitalization on colors?
blue is not capitalized is it?,
but certain shades of blue might be?
. I confused because I'm sure
days of the week are capitalized,
and I see no difference between
energy bands for colors,
and time bands across each week .
. well, anyway, don't bother expecting
types in adda to be capitalized;
that would just be more confusing, not less .
web.engl/capitalization rules:
concerning colors:
. are colors supposed to be capitalized ?
yes, no, no, and no .
colors vs days of week:
. most are named after roman or greek gods
eg, Friday--Freyas Day,
so they kept the capital letter.
. time sections start with a capital letter
in English, and German, but not in French or Spanish .
. wiki has a list of international capitalization variations;
eg, the english seem to have retained the rules of Latin .
. did you notice the capitalization on colors?
blue is not capitalized is it?,
but certain shades of blue might be?
. I confused because I'm sure
days of the week are capitalized,
and I see no difference between
energy bands for colors,
and time bands across each week .
. well, anyway, don't bother expecting
types in adda to be capitalized;
that would just be more confusing, not less .
web.engl/capitalization rules:
concerning colors:
. are colors supposed to be capitalized ?
yes, no, no, and no .
colors vs days of week:
. most are named after roman or greek gods
eg, Friday--Freyas Day,
so they kept the capital letter.
. time sections start with a capital letter
in English, and German, but not in French or Spanish .
. wiki has a list of international capitalization variations;
eg, the english seem to have retained the rules of Latin .
(is) vs (=)
12.14: adda/(is) vs (=):
. math is a lang centered around var's,
whereas english's (is) would have to be explicit about
a var being involved;
so, for math's x=c, where c is some constant,
english might say "( x's current value is c ).
. math is a lang centered around var's,
whereas english's (is) would have to be explicit about
a var being involved;
so, for math's x=c, where c is some constant,
english might say "( x's current value is c ).
librarians that do Make
12.14: co.self/dream/adda/librarians that do Make:
. in a compiler system, the info managed by the Make file,
can instead by generated by the library;
the info to be gathered by the linker
includes the hashes of everything that is linked
(so it knows when anything has been modified)
and a database of which wares are required each other;
it is builing a requires-list for
each piece that got linked to anything ...
[. upon waking,
I started looking around for how usable that was;
actually, a hash of each module is not the only thing you want;
because, if an impl' has changed but its interface has not,
then the libary should not need to recompile it .
because it's still promising to serve the same interface as before .
1118:
. however, you would want to do re-apply
any unit testing scripts,
and then passing that would also trigger
any related integration testing scripts .]
12.14: adda/librarians that do Make:
. as the compiler is generating binaries from text,
the Make file is the place for describing dependencies;
so then, if a dependency can be checked for freshness:
if the source text in newer than the binary,
then it needs to be recompiled .
. if the inteface is newer than the binary,
then all clients need to be recompiled .
. we routinely reuse binaries from others;
(most people are users, not developers)
and, so, for a compiler to be doing
Make file duties,
it needs to be exchanging Make info
with other compilers .
. to know if an import is serving a particular interface
it actually needs a text or symbolic version of that interface
which needs to resove to the same typenames,
or optionally to any similar datatype,
depending on whether the given type describes itself as
new
where it simply uses other types for implementing its model,
it doesn't expect to be seen as a synonym for the type it used .
. the ada lang allows both new types and reuse of types;
ie, a new type means you have an impl reusing an old type
but you don't want to be seen as being compatable with the old type,
you want to be compat only to your name
or at least only to the interface your name represents .
. eg,
a character string may be impl'd as a c string, or a safe string,
but both are serving the same model, type"string;
whereas, gasoline tank may be an integer modeling volume,
but it doesn't want to be confused with other integers,
nor operated on by just anything that can modify integers .
. we have ideas for features addx should have,
make sure to separate that from how features should be impl'd .
. if there's a new version with a fix from an exporter,
your librarian needs to accept it
but if it's accepting c or python code,
then user needs to be informed that the system is less secure
if they go ahead with reuse by non-adda coders .
(the reason you're safe with adda code,
is that it's compiled by adda, a trusted app
-- unless your machine's os has been
compromised by malware --
adda code has been translated into python or c,
which can be trusted as much python's core library,
and your own os (that depends on
your own security policy:
do you run your browser in a vm?
keep your os updated?
know where your usb drives have been? ...)
sync's:
. the model that the librarian needs to have in order to
accept imports,
is to accept sync's with other librarians
and then synchs download interfaces of sharables
so your librarian can list them when you've asked what's available .
. if you do use an external,
it downloads the associated body,
the list shows too where your names conflict .
. it doesn't require you to rename conflicts because
all listings are qualified by the exporting librarian's name,
except for the entries of the local librarian .
. the user's rename can make an export appear to be local,
while yet being maintained by an exporter .
. local librarian is thus a language translator,
having a separate set of names for {user, other librarians}.
12.14: todo.adda/unify sync'd librarians with version control systems:
. the need to unify sync'd librarians
has to do with version control systems .
. in a compiler system, the info managed by the Make file,
can instead by generated by the library;
the info to be gathered by the linker
includes the hashes of everything that is linked
(so it knows when anything has been modified)
and a database of which wares are required each other;
it is builing a requires-list for
each piece that got linked to anything ...
[. upon waking,
I started looking around for how usable that was;
actually, a hash of each module is not the only thing you want;
because, if an impl' has changed but its interface has not,
then the libary should not need to recompile it .
because it's still promising to serve the same interface as before .
1118:
. however, you would want to do re-apply
any unit testing scripts,
and then passing that would also trigger
any related integration testing scripts .]
12.14: adda/librarians that do Make:
. as the compiler is generating binaries from text,
the Make file is the place for describing dependencies;
so then, if a dependency can be checked for freshness:
if the source text in newer than the binary,
then it needs to be recompiled .
. if the inteface is newer than the binary,
then all clients need to be recompiled .
. we routinely reuse binaries from others;
(most people are users, not developers)
and, so, for a compiler to be doing
Make file duties,
it needs to be exchanging Make info
with other compilers .
. to know if an import is serving a particular interface
it actually needs a text or symbolic version of that interface
which needs to resove to the same typenames,
or optionally to any similar datatype,
depending on whether the given type describes itself as
new
where it simply uses other types for implementing its model,
it doesn't expect to be seen as a synonym for the type it used .
. the ada lang allows both new types and reuse of types;
ie, a new type means you have an impl reusing an old type
but you don't want to be seen as being compatable with the old type,
you want to be compat only to your name
or at least only to the interface your name represents .
. eg,
a character string may be impl'd as a c string, or a safe string,
but both are serving the same model, type"string;
whereas, gasoline tank may be an integer modeling volume,
but it doesn't want to be confused with other integers,
nor operated on by just anything that can modify integers .
. we have ideas for features addx should have,
make sure to separate that from how features should be impl'd .
. if there's a new version with a fix from an exporter,
your librarian needs to accept it
but if it's accepting c or python code,
then user needs to be informed that the system is less secure
if they go ahead with reuse by non-adda coders .
(the reason you're safe with adda code,
is that it's compiled by adda, a trusted app
-- unless your machine's os has been
compromised by malware --
adda code has been translated into python or c,
which can be trusted as much python's core library,
and your own os (that depends on
your own security policy:
do you run your browser in a vm?
keep your os updated?
know where your usb drives have been? ...)
sync's:
. the model that the librarian needs to have in order to
accept imports,
is to accept sync's with other librarians
and then synchs download interfaces of sharables
so your librarian can list them when you've asked what's available .
. if you do use an external,
it downloads the associated body,
the list shows too where your names conflict .
. it doesn't require you to rename conflicts because
all listings are qualified by the exporting librarian's name,
except for the entries of the local librarian .
. the user's rename can make an export appear to be local,
while yet being maintained by an exporter .
. local librarian is thus a language translator,
having a separate set of names for {user, other librarians}.
12.14: todo.adda/unify sync'd librarians with version control systems:
. the need to unify sync'd librarians
has to do with version control systems .
passing destination references implicitely
12.9: adda/translate/passing destination references implicitely:
. by passing destination locations as references
instead of having functions return objects,
we can avoid a lot of garbage generation,
but the reason oop doesn't do this is it complicates the job of
application programmers .
. the reason addx does do this, is it has a translator
that does this automatically for programmers:
the compiler is looking for their y`= f(x)
and converting it for them into f-proc(&y, x).
. I think I had a contradictory example somewhere,
but it only applies to when the library programmer is
wanting to do systems programming (when it extends the compiler).
. by passing destination locations as references
instead of having functions return objects,
we can avoid a lot of garbage generation,
but the reason oop doesn't do this is it complicates the job of
application programmers .
. the reason addx does do this, is it has a translator
that does this automatically for programmers:
the compiler is looking for their y`= f(x)
and converting it for them into f-proc(&y, x).
. I think I had a contradictory example somewhere,
but it only applies to when the library programmer is
wanting to do systems programming (when it extends the compiler).
else-if statement's syntax
12.10: adda/cstr/else-if:
. here is the if-else syntax:
t?
( c1: s1
, c2: s2
, else: s3
) .
if I add an elsif to the structure, how does that fit in ?;
actually, with the use of (?) instead of (if)
there's maximum brevity without using a
contraction of [else if] .
. using that case-style syntax, it'd look like this:
t1 ? ( s1
, else: t2 ? (s3
, else: t4 ? (s5
, else: s6 ))).
. using truth-style syntax, it looks normal:
t1 ? s1
else t2 ? s3
else t4 ? s5
else s6 .
-- neat, but since (if) doesn't have a terminator
(like ada's endif,
any nested if-else's have to be parenthesized
as do any statement sequences:
t1 ?
s1
else t2 ?
(t1 ? s1 else t2 ? s3 else t4 ? s5 else s6 )
else t4 ?
(s1; s2)
else
s6 .
[if vs ?]:
. if you'd rather use if's, then (t?) is generally
replaceable with (if t:); ie,
the (:) is acting as a terminator like the (?) does .
mis:
. at first I was seeing it as a case stmt
with more than one case possible
the thing need to be ordered
reminds of using (;) instead of (,)
as is structuring arrays into matrices .
even if I could make the matrix pattern fit,
I'm not sure a tired or new programmer could
keep a working knowledge of it .
sci:
. notice that since both of (if)'s args are required,
then you could also separate them with a space
like lisp does; in that case,
you'd be detecting the condition where
the next token in the 2nd arg has to be an infix
but instead you found a non-infix;
however, that wouldn't work in my current syntax,
because infix's can also serve as prefix's;
so the (if)'s arg's do need a separator,
and a natural for that situation is the colon .
then again:
. you could also tell that the (if)'s 2nd arg began
because the next infix you were expecting
would have to be a truth-operator, ie:
{ or, and; nor, nand,
<=>, -- x is/not equivalent to y ( is also called xor, exclusive-or),
=>, =/> -- x does/not imply y,
<=, }
another prequisite:
. the other problem with not using the colon,
is that you can no longer have overloading;
you'd have to reserve the logical operators;
and while it does add unnecessarily to bureaucracy,
it would aid considerably to readability .
nevertheless:
. speaking of readability, use of the separator would
make it easy for humans to quickly parse;
and while adda should let writers skip the separator,
it should provide the readers the option of viewing it;
ie, it would be part of the
full vs minimized punctuation theme .
the deal breaker:
. finally, an insurmountable problem is one of
users adding more binary logic operators,
or similar functions of the form:
(truth, other-type)->truth .
. they should be able to do that,
so, you'd also have to make a general rule about
no overloading of such,
and that would be too much bureacracy
for the sake of merely simplifying (if)'s .
list of truth-operators:
. here is a table of possible combinations on 2 variables, x,y;
and the operations that can detect those combinations .
(~x&~y, ~x&y, x&~y, x&y) -- operation:
------------------------------------------
0000 -- false (regardless of inputs)
0001 -- x&y -- x and y
0010 -- x&~y -- not( ~x or y) -- x =/> y
0011 -- x (regardless of y)
0100 -- ~x&y -- not (x <= y)
0101 -- y (regardless of x)
0110 -- ~x&y or x&~y -- xor --
0111 -- x or y
1000 -- ~x&~y -- not(x or y) -- nor
1001 -- ~x&~y or x&y -- <=>
1010 -- ~y (regardless of x)
1011 -- not (~x&y) -- x or ~y -- x <= y
1100 -- ~x (regardless of y)
1101 -- not(x&~y) -- ~x or y -- x => y
1110 -- not(x&y) -- ~x or ~y -- nand,
1111 -- true (regardless of inputs)
the same rearranged by category:
non-binary logic:
truth values:
0000 -- false (regardless of inputs)
1111 -- true (regardless of inputs)
variable values:
0011 -- x (regardless of y)
1100 -- ~x (regardless of y)
0101 -- y (regardless of x)
1010 -- ~y (regardless of x)
classic binary logic:
0001 -- x and y
0111 -- x or y
1101 -- not(x&~y) -- ~x or y -- x => y
0010 -- x&~y -- not( ~x or y) -- x =/> y
1001 -- ~x&~y or x&y -- <=>
0110 -- ~x&y or x&~y -- xor --
modern binary logic:
1110 -- not(x&y) -- ~x or ~y -- nand,
1000 -- ~x&~y -- not(x or y) -- nor
english binary logic:
1011 -- not (~x&y) -- x or ~y -- x <= y -- implied by
0100 -- ~x&y -- not (x <= y) -- not implied by
. here is the if-else syntax:
t?
( c1: s1
, c2: s2
, else: s3
) .
if I add an elsif to the structure, how does that fit in ?;
actually, with the use of (?) instead of (if)
there's maximum brevity without using a
contraction of [else if] .
. using that case-style syntax, it'd look like this:
t1 ? ( s1
, else: t2 ? (s3
, else: t4 ? (s5
, else: s6 ))).
. using truth-style syntax, it looks normal:
t1 ? s1
else t2 ? s3
else t4 ? s5
else s6 .
-- neat, but since (if) doesn't have a terminator
(like ada's endif,
any nested if-else's have to be parenthesized
as do any statement sequences:
t1 ?
s1
else t2 ?
(t1 ? s1 else t2 ? s3 else t4 ? s5 else s6 )
else t4 ?
(s1; s2)
else
s6 .
[if vs ?]:
. if you'd rather use if's, then (t?) is generally
replaceable with (if t:); ie,
the (:) is acting as a terminator like the (?) does .
mis:
. at first I was seeing it as a case stmt
with more than one case possible
the thing need to be ordered
reminds of using (;) instead of (,)
as is structuring arrays into matrices .
even if I could make the matrix pattern fit,
I'm not sure a tired or new programmer could
keep a working knowledge of it .
sci:
. notice that since both of (if)'s args are required,
then you could also separate them with a space
like lisp does; in that case,
you'd be detecting the condition where
the next token in the 2nd arg has to be an infix
but instead you found a non-infix;
however, that wouldn't work in my current syntax,
because infix's can also serve as prefix's;
so the (if)'s arg's do need a separator,
and a natural for that situation is the colon .
then again:
. you could also tell that the (if)'s 2nd arg began
because the next infix you were expecting
would have to be a truth-operator, ie:
{ or, and; nor, nand,
<=>, -- x is/not equivalent to y ( is also called xor, exclusive-or),
=>, =/> -- x does/not imply y,
<=, }
another prequisite:
. the other problem with not using the colon,
is that you can no longer have overloading;
you'd have to reserve the logical operators;
and while it does add unnecessarily to bureaucracy,
it would aid considerably to readability .
nevertheless:
. speaking of readability, use of the separator would
make it easy for humans to quickly parse;
and while adda should let writers skip the separator,
it should provide the readers the option of viewing it;
ie, it would be part of the
full vs minimized punctuation theme .
the deal breaker:
. finally, an insurmountable problem is one of
users adding more binary logic operators,
or similar functions of the form:
(truth, other-type)->truth .
. they should be able to do that,
so, you'd also have to make a general rule about
no overloading of such,
and that would be too much bureacracy
for the sake of merely simplifying (if)'s .
list of truth-operators:
. here is a table of possible combinations on 2 variables, x,y;
and the operations that can detect those combinations .
(~x&~y, ~x&y, x&~y, x&y) -- operation:
------------------------------------------
0000 -- false (regardless of inputs)
0001 -- x&y -- x and y
0010 -- x&~y -- not( ~x or y) -- x =/> y
0011 -- x (regardless of y)
0100 -- ~x&y -- not (x <= y)
0101 -- y (regardless of x)
0110 -- ~x&y or x&~y -- xor --
0111 -- x or y
1000 -- ~x&~y -- not(x or y) -- nor
1001 -- ~x&~y or x&y -- <=>
1010 -- ~y (regardless of x)
1011 -- not (~x&y) -- x or ~y -- x <= y
1100 -- ~x (regardless of y)
1101 -- not(x&~y) -- ~x or y -- x => y
1110 -- not(x&y) -- ~x or ~y -- nand,
1111 -- true (regardless of inputs)
the same rearranged by category:
non-binary logic:
truth values:
0000 -- false (regardless of inputs)
1111 -- true (regardless of inputs)
variable values:
0011 -- x (regardless of y)
1100 -- ~x (regardless of y)
0101 -- y (regardless of x)
1010 -- ~y (regardless of x)
classic binary logic:
0001 -- x and y
0111 -- x or y
1101 -- not(x&~y) -- ~x or y -- x => y
0010 -- x&~y -- not( ~x or y) -- x =/> y
1001 -- ~x&~y or x&y -- <=>
0110 -- ~x&y or x&~y -- xor --
modern binary logic:
1110 -- not(x&y) -- ~x or ~y -- nand,
1000 -- ~x&~y -- not(x or y) -- nor
english binary logic:
1011 -- not (~x&y) -- x or ~y -- x <= y -- implied by
0100 -- ~x&y -- not (x <= y) -- not implied by
exceptions - events declared in the interface
adda/type/exceptions/events declared in the interface:
. the singleton pattern in the cocoa text has an example
where some device mgt needs to know when the app is closing
(ie, the app class provides a notification service,
and it needs to be registered with this service).
. generally,
if there is an event that type mgt needs,
declaring it in its interface should register it
to receive notifcations of any such events .
. notifications are interrupting the control flow
but unlike during ada exceptions,
the flow can return back to its routine .
. the singleton pattern in the cocoa text has an example
where some device mgt needs to know when the app is closing
(ie, the app class provides a notification service,
and it needs to be registered with this service).
. generally,
if there is an event that type mgt needs,
declaring it in its interface should register it
to receive notifcations of any such events .
. notifications are interrupting the control flow
but unlike during ada exceptions,
the flow can return back to its routine .
exceptions - when to use error logging instead
adda/cstr/exceptions/when to use error logging instead:
. if the misuse of an interface will be caught during compilation
then a logged warning is appropriate;
otherwise, the bug catch will be depending on
how much testing the client coder does,
so if the bug gets to the user,
there should be an exception to get some runtime backup;
ie, the code will be responding to exceptions with
certain fixes or apologies;
conversely, if the coder isn't catching exceptions
then that is some half-baked, dangerous code,
and the user should be made aware it
so then the denial of service implied by an uncaught exception
is warranted .
. if the misuse of an interface will be caught during compilation
then a logged warning is appropriate;
otherwise, the bug catch will be depending on
how much testing the client coder does,
so if the bug gets to the user,
there should be an exception to get some runtime backup;
ie, the code will be responding to exceptions with
certain fixes or apologies;
conversely, if the coder isn't catching exceptions
then that is some half-baked, dangerous code,
and the user should be made aware it
so then the denial of service implied by an uncaught exception
is warranted .
ada`separate addressing the overloaded
adda/syntax/ada`separate/addressing the overloaded:
. how is adda saying the full name of a nested subroutine,
like ada says separate is ... ? use keyword body func`body,
. functions can be overloaded (ie,
different functions with the same name
but distinguished by unique signatures),
so then the full path name may need to include the signature:
eg, func(t1,t2)`body/subroutine .
. how is adda saying the full name of a nested subroutine,
like ada says separate is ... ? use keyword body func`body,
. functions can be overloaded (ie,
different functions with the same name
but distinguished by unique signatures),
so then the full path name may need to include the signature:
eg, func(t1,t2)`body/subroutine .
possessive right for component selection?
12.3: proj.adda/syntax/possessive right for component selection?:
. I've been overloading the possessive for use as
both an obj`call and an obj`component,
any complications?
. wasn't there some new idea for record syntax,
like obj.component? yes:
http://amerdreamdocs.blogspot.com/2011/04/rethinking-aggregates.html
. the consequence was,
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),
but most would rather write .int than .Z .
. adde can help out by auto-formatting types in a bold font .
. I've been overloading the possessive for use as
both an obj`call and an obj`component,
any complications?
. wasn't there some new idea for record syntax,
like obj.component? yes:
http://amerdreamdocs.blogspot.com/2011/04/rethinking-aggregates.html
. the consequence was,
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),
but most would rather write .int than .Z .
. adde can help out by auto-formatting types in a bold font .
rom vs const
12.2: adda/cstr/rom vs const:
what did rom vs const mean?
. the use of a "rom" designation only makes sense when sharing;
because, const means it's rom even to self
(ie, no writes after init) .
. the rom and const could reuse the same symbol
since when a param says const
that's the same as promise to the caller that it'll be
treated as read-only: ie, const.
. const is like in-mode and that is the default mode;
12.3:
. there is still the issue of what happens to a param later;
eg, when my formal param uses the constant specifier,
it assures not only that it won't do any modifications
but also that it won't pass the obj to a modifying function .
. another issue is compatability:
{mutable, contst} can be assigned to const;
only mutable can assigned to mutable
(a param is mutable when declared as inout-mode ).
. due to obj's having access to themselves,
whether an operation of theirs is really read-only
is totally up to them their private implementations
unless the system can detect when they write .
. if the system can't detect that,
there will have to be more copying to assure modularity .
12.2:
. one efficiency trick for reducing the amount of copying,
is to wait for an attempted write
before doing the copy .
12.3:
. once the run-time mgt can detect writes to a rom,
it needs to raise an exception,
so, to avoid such messes,
param providers and their compilers
need to know what operations are modifiers .
. the way operations are described in an interface,
(`f) is assumed to be self-modifying
unless it states otherwise;
for f to be seen as non-modifying
it should be defined as a function
(ie, not out-mode params or side-affects)
or be tagged as non-modifying:
( !`f ).
what did rom vs const mean?
. the use of a "rom" designation only makes sense when sharing;
because, const means it's rom even to self
(ie, no writes after init) .
. the rom and const could reuse the same symbol
since when a param says const
that's the same as promise to the caller that it'll be
treated as read-only: ie, const.
. const is like in-mode and that is the default mode;
12.3:
. there is still the issue of what happens to a param later;
eg, when my formal param uses the constant specifier,
it assures not only that it won't do any modifications
but also that it won't pass the obj to a modifying function .
. another issue is compatability:
{mutable, contst} can be assigned to const;
only mutable can assigned to mutable
(a param is mutable when declared as inout-mode ).
. due to obj's having access to themselves,
whether an operation of theirs is really read-only
is totally up to them their private implementations
unless the system can detect when they write .
. if the system can't detect that,
there will have to be more copying to assure modularity .
12.2:
. one efficiency trick for reducing the amount of copying,
is to wait for an attempted write
before doing the copy .
12.3:
. once the run-time mgt can detect writes to a rom,
it needs to raise an exception,
so, to avoid such messes,
param providers and their compilers
need to know what operations are modifiers .
. the way operations are described in an interface,
(`f) is assumed to be self-modifying
unless it states otherwise;
for f to be seen as non-modifying
it should be defined as a function
(ie, not out-mode params or side-affects)
or be tagged as non-modifying:
( !`f ).
syntax for readonly, const, out, inout, persistent
12.2: adda/type/syntax for readonly, const, out, inout, persistent:
todo:
. need to review or finish the type syntax .
.#./.txt
.#./!.txt! -- array of const pointer to const text,
A ^#.txt -- persistent array of text,
[12.3:
. this would be a lot more readable if the (!) was simply replacing the (.)
#!/!txt -- the (!) would then be translated as "(return const ...)
-- that says type is array return const pointer to return constant text .
...
however, it doesn't address all needs:
for operations over self ( declared as x`f().t )
how do you say `f is readonly? ]
12.5: read-only operations:
. in places where !`f might say
(operation over obj is readonly)
[1039: adde's english mode should apply to commands too;
it would display footnotes of what a command does
in a twitter sized message . the footnotes would be at each step;
so also below any complete algebraic expression .]
the problem with consistency is that you're not using the same syntax
where dot is showing the obj type being returned .
. there were 2 situations for rom or const:
# rom for params ie sharing ,
# const for your own obj's .
. in the case of x`f(), you're looking to express rom on a param
but the param is implicit, so then you need to make it explicit:
(o!T)`f -- a read-only operation;
(o.T)`f, `g -- mutating operations .
todo:
. need to review or finish the type syntax .
.#./.txt
.#./!.txt! -- array of const pointer to const text,
A ^#.txt -- persistent array of text,
[12.3:
. this would be a lot more readable if the (!) was simply replacing the (.)
#!/!txt -- the (!) would then be translated as "(return const ...)
-- that says type is array return const pointer to return constant text .
...
however, it doesn't address all needs:
for operations over self ( declared as x`f().t )
how do you say `f is readonly? ]
12.5: read-only operations:
. in places where !`f might say
(operation over obj is readonly)
[1039: adde's english mode should apply to commands too;
it would display footnotes of what a command does
in a twitter sized message . the footnotes would be at each step;
so also below any complete algebraic expression .]
the problem with consistency is that you're not using the same syntax
where dot is showing the obj type being returned .
. there were 2 situations for rom or const:
# rom for params ie sharing ,
# const for your own obj's .
. in the case of x`f(), you're looking to express rom on a param
but the param is implicit, so then you need to make it explicit:
(o!T)`f -- a read-only operation;
(o.T)`f, `g -- mutating operations .
c's static internal vars
12.2: adda/cstr/c's static internal vars:
. c's static internal vars are can applied in obj'c
to both {class, instance} methods and functions .
. persistence is the essence of c's static internal vars:
they are locally scoped within a function,
yet retain their value between calls to the function .
. it's as if the modules that contain these functions
are keeping these "(locals) at their top level;
so for T.type/f.proc/x.txt
you might see the var is actually at
T`body/f.proc'space/x.txt .
. for a progam, it's actually structured as a package:
(main, subroutine, globals), so local static looks like:
program/Subroutine'space/x.txt .
. what does that look like in adda?
. my first idea was asserting that
part of simplicity is naming things after
the way they are actually structured;
but after seeing how verbose that was,
I'm looking at a functional keyword:
persistent (with brief symbol = (^)
-- an amusing reference to christian's one-way ).
. c's static internal vars are can applied in obj'c
to both {class, instance} methods and functions .
. persistence is the essence of c's static internal vars:
they are locally scoped within a function,
yet retain their value between calls to the function .
. it's as if the modules that contain these functions
are keeping these "(locals) at their top level;
so for T.type/f.proc/x.txt
you might see the var is actually at
T`body/f.proc'space/x.txt .
. for a progam, it's actually structured as a package:
(main, subroutine, globals), so local static looks like:
program/Subroutine'space/x.txt .
. what does that look like in adda?
. my first idea was asserting that
part of simplicity is naming things after
the way they are actually structured;
but after seeing how verbose that was,
I'm looking at a functional keyword:
persistent (with brief symbol = (^)
-- an amusing reference to christian's one-way ).
subclassing without sideaffects
12.22: todo.adda/oop/subclassing without sideaffects:
. how does the oop remain secure, and yet reusable?
they are having a lot of fun with subclassing,
so, is there any way to do that safely ?
the general idea is that it creates sideaffects,
so not only do you want to enforce capability limits on apps,
you also want to warn users when an app uses side-affecting features .
. you want to bar cap'grabbing features
like the obj'c categories which allow adding slots to library classes;
however, need to get more aquainted with
why they feel that is needed,
and find some alternative .
. how does the oop remain secure, and yet reusable?
they are having a lot of fun with subclassing,
so, is there any way to do that safely ?
the general idea is that it creates sideaffects,
so not only do you want to enforce capability limits on apps,
you also want to warn users when an app uses side-affecting features .
. you want to bar cap'grabbing features
like the obj'c categories which allow adding slots to library classes;
however, need to get more aquainted with
why they feel that is needed,
and find some alternative .
class methods
12.2: adda/oop/class methods:
. how does adda do an objc class method?
. there are notes already but here's review:
t.type: ((instance methods declared here));
t`classmethod().proc -- a class method
. you could also have everything in the interface,
distingishing {class, instance} with the usual keywords:
# self`f(x), `f(x) -- instance method (the default)
# class`g(x) -- class method .
[12.3:
. this basically mirrors the way obj'c does it .]
. how does adda do an objc class method?
. there are notes already but here's review:
t.type: ((instance methods declared here));
t`classmethod().proc -- a class method
. you could also have everything in the interface,
distingishing {class, instance} with the usual keywords:
# self`f(x), `f(x) -- instance method (the default)
# class`g(x) -- class method .
[12.3:
. this basically mirrors the way obj'c does it .]
Subscribe to:
Posts (Atom)
