Joy, Dolphin, Memory Management (was: Joy, FORTH, ...)

[Kyle Lahnakoski]

iepos@tunes.org wrote:

> Interesting... One question... how are you planning on implementing lists?
> I'm guessing you're going to supply special primitives for lists,
> and distinguish them from quoted programs (unlike Joy)... But then,
> the question is: are you going to keep the lists all in one piece,
> or are you going to split them up, and link the pieces with pointers?
> This seems like quite an important thing, as lists I'm guessing
> will play quite an important role in the system, and their efficiency
> will largely determine the efficiency of the whole system...

Question:  Are lists planning to be primitive?  And if so why?

Lists have been used much, but most often they are used when other
structures are more descriptive is intended functionality.  I do not
believe lists should be a primitive structure (a primitive structure is
one that is necessary for the reflective system).  I use tables and
parameterized sets.  Consider a function call, its parameters are a
list:

	MyFunction(a, b, c);

This is wrong.  The meaning of the parameters depends on location, and
is hidden from the reflective system.  With parameterized sets we have
the same function:

	MyFunction(Name=a, Age=b, Spouse=c);

Now the reflective system, and the programmer, know what the parameters
are for.
	
	MyFunction(Age=b, Name=a);

Look!  The artificial dependency on order is gone, we have extra benefit
of implying default values!  The use of parameterized sets are more
descriptive and have less implications than the list.  Unfortunately
parameterized sets are finite.

I will add here that I dislike the order C programmers put their
parameters; most 'important' first.  When calling functions that first
parameter is used over and over again, it is the right-most parameters
that are most relevant in a given context.  It was the initial reason
lists were eliminated.

	E.G.
		file=open(filename);
		write(file, "Hi there");
		write(file, "What are you doing");
		close(file);

	I prefer
		file=open(filename);
		write("Hi there", file);
		write("What are you doing", file);
		close(file);




The table is used to cover the variable-length aspect of a list.  Table
has the advantage of not implying order if there need not be any.  The
backend can determine the best method of storing the data, there is a
whole DB theory on that.

An example: When handling generic messages, the number of parameters are
not known.  An extraction to a table can be made for the parameters:

	Parameters_Of_A_Message_Table
	Field		Value
	--------	-----
	Name		a
	Age		b
	Spouse		c


Lists are necessary when they are important to the logic of the object
modeled.  So I do implement lists, but they are not primitive.

	List_Element_Class
		List_Element_Class next;
		Object_Class object;

	List_Class
		List_Element_Class head;

The demand for parameterized sets (psets), and tables creates a very
different paradigm from traditional computing.  The concept of a file (a
large list) is not dealt with very well by just psets and tables. 
Everything currently stored in files in an OS must be broken down into
its logical components.  This is obvious from a Tunes perspective, but
also from a pset/table perspective.  I strongly suspect that psets and
tables are excellent primitive storage structures once the contents of
files are interpreted.

The worst case I have come up with, that psets and tables do not
efficiently handle, is human text, everything else are serialized
objects.  But human text, until it can be understood by AI, is a
serialized version of concepts that can not be decoded.  Some progress
can be made by identifying words, sentences and paragraphs as objects to
reduce the average list size used to store human text.

Please excuse me if this has been covered.











----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com