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

[btanksley@hifn.com]

From: Kyle Lahnakoski [mailto:kyle@arcavia.com]

>iepos@tunes.org wrote:

>> Interesting... One question... how are you planning on 
>> implementing lists?

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

Not in the sense in which you mean it.

>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).

My system is not inherently reflective; I'm not that far along.  However,
there are certain parts of it which are intended to provide introspection;
the main one of those is "quotations".  A quotation is a program stored in a
manner which makes it easy to examine and modify.

My quotations are currently arrays: more specifically, they're a continguous
group of zero or more "xt"s stored in a byte-addressed memory buffer.  An xt
is four bytes long, and is in fact a pointer to a structure which describes
the function it names.

>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.

This is good for an applicative function call -- but what if your function
calls are not applicative?  In other words, what if the system isn't told
what items will be applied to each function until runtime?  Postscript is
the most common example of a non-applicative language; Forth is as well, and
is more commonly hand-written.

>The demand for parameterized sets (psets), and tables creates a very
>different paradigm from traditional computing.

Yes -- it's a very interesting one.

>The concept of a file (a
>large list) is not dealt with very well by just psets and tables. 

I've always thought that files were rather stupid, anyhow.

>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 interesting thing about this is that it's likely that the result is more
similar to how the files are actually stored on disk, as well as being
easier to use for real applications.  (Depends on how your "filesystem"
works.)

>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.

http://www.sil.org/htbin/search-softcat.pl?kw=parser.  Of course, this is
not generally the best way to handle text; a better way is to treat is "as
entered".

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy