tunes-0.0.1.c

RE01 Rice Brian T. EM2 BRice@vinson.navy.mil
Mon, 23 Nov 1998 17:08:48 +1100



>ideas for the data-format:
>	-a doubly-linked 'web' (for n-ary relations)
>	-dynamically resizeable regions of memory allocated to objects
>	-(an appropriate garbage collector / re-positioner of data will soon be
>necessary)
>	-an auxiliary file for storing hash-tables for strings which will name
>desired objects (obviously containing pointers to those objects).
>	-the double-links should contain information about the type of link, i.e.
>they should point to the relation object.
>	+any suggestions??

well, here's some more input to the group, now that the busiest part of
the deployment for me is completed:

i'd like to start with the idea of constructing worlds from graphs
(multi-graphs and such), and allowing 'higher-order' statements to be
made via arrows whose nodes may be arrows or groups of arrows, instead
of necessarily indescribable atoms.  this is intended as the mechanism
for knowledge-level reflection in the base system (that system where the
context is constant).  i'm not sure how to implement inifinitary shapes
of arrows in a way which does not violate the simplicity of the
data-structure format, while still allowing a simple axiomatic
'machine-model' definition as we have discussed.

i haven't had much time to think about this recently, but that has
changed, possibly permanently, within the last day or so.

anyway, my first and most straight-forward idea is to implement arrows
in a linked-vector style fashion, with contiguous data structures for
each arrow.  the arrow's primary (first-order) identification could be
by its address, with its two fields denoting the 'head' and 'tail' of
the arrow.  i know that this sounds identical with lisp-style lists,
because it is in the previous respect.  however, the semantics of this
system will be allowed more generality by a complete lack of assumption
of a 'tree-like' shape of arrows, and the corresponding lack of
restriction over which arrows are pointed to for any given arrow.

it should be easily possible to allow for a compactification of the
low-level representation of this system by creating the appropriate
'ordered tuple' representation of binary trees.  however, my first gut
reaction tells me that the variable-length objects created may
complicate any garbage-collection scheme we would desire to include, as
well as complications in object-addressing (referencing) mechanisms.
also, the decision by the system to create ordered tuples may turn out
to be arbitrary with respect to the user's point of view on the system.
i think that this should be left out until a solution can be found.

another possible optimization would be to represent small arrow-graphs
via incidence matrices (where the value of a matrix element corresponds
to the presence of an arrow between the row node and column node).
however, this system would make arrow referencing for 'sister' arrows in
multi-graphs quite difficult, and so i will avoid it for now unless
someone has a simple solution for their implementation.

anyway, if you have any feedback for this approach, please share, as i
have begun coding a scheme (pun intended) for this in posix-like c code
for linux.  i still believe that the hash-table with strings and
references will be quite indispensible for a while.

also, if anyone knows that a system which should handle these _initial_
properties quite readily (like self, for instance) without the overhead
of arithmetic and other standard constructs, please forward source-code
to me (don't send attachments, because my mail reader is lame and won't
accept them).  also, if anyone could help me deal with the issues of how
to represent infinitary structures of these arrows using a combination
of finite structures and added semantics to the machine-model
definition, then share your ideas, even if they aren't explicit
solutions, because they might inspire my mind in the right direction.

btw, if anyone knows of a better interface for maintaining object
references in the system i am describing other than by explicit pointers
(or just as complicatedly, by graphical-arrow representation), then
please share the idea, since my system as it stands will require lots of
searches or lots or reference-counters for a garbage-collector.

and, yes, harsh critiques are quite welcome.  i find very little
reasoning ability or interest among the people with which i work and
live, and so my mind tends become complacent in reasoning rather easily.