Lists, Tables, Psets (Was: Joy, Dolphin, ...)

[Kyle Lahnakoski]

iepos@tunes.org wrote:

>   i:    takes a program off the stack and executes it
>   dip:  takes a program off the stack and executes it, but first
>         saves the next stack item, so that the program cannot touch it,
>         which is restored after the program completes.
>   cons: takes a program off the stack, and a stack item beneath it,
>         and yields a new program that is like the original except
>         that when it is executed the stack item will be pushed
>         first.

Thank you.

> In general, it is most natural for parameters to be used in the
> reverse order that they were pushed.

Yes, but who is to say that is the same "natural" order to push those
values onto the stack to make a function call?



> > The former method is shorter than the latter, but only in human text.
> > Your stack-based system would do the following
> >
> >       push a
> >       push b
> >       push c
> >       MyFunction
> 
> Whoa... there is no need for "push". Just do "a b c MyFunction".
> This is not just human text; this how one would actually do
> it in a programming system. See the Joy system for an example.

My questions are: 
What is the data structure used to store a call to the MyFunction?
What is the data structure used to define the interface for MyFunction?



> This I can accept, I guess. But, remember that in saying that the
> Joy-like approach uses a stack, I do not mean that it need only
> run well on stack machines; it could be made to run well on machines
> with fixed registers also. Perhaps it would help to think of the stack
> as an abstract thing, as you would psets in your system, rather than
> as a low level thing, modelling the processor's low-level stack.

Of course.  I worry about the complexity of the logic required to
optimize code for a fixed register machine.  We can modularize the
process for optimization:

	Joy Code -> Logical Intent -> Machine Code

I am saying that the "Logical Intent" is the right representation. 
Maybe you are right about it being bloated, but that is because it
contains more explicit information.



> Hmm... I guess I know little of DB theory...

Let me think about that.  I will try to get you a reference that
contains a high information density.  DB theory was my convincing
argument to use psets.



> > My main point is that the use of ordered structures to encode meaning
> > seems wrong to me.
> 
> Interesting... but, I'd still have to say that it does not seem wrong
> to me.

I am sure we would both like to convert the other. :-)



> Hmm... and what about the case of arithmetic operators like +, -, *, and / ?
> It seems like you'd have to make an exception for them and allow
> the ordering to be significant, or else the code will be really
> bloated... for instance, in your kind of system how would you
> write "(2+3) * (4+5)" ? In a Joy-like system, it would be written

Great! ;-)  You ask for the hardest example.  The +-*/ operators are one
of the few most primitive functions.  These functions are part of the
assembler so that numbers are objects, unlike most other languages.

Consider my Divide_Integer function:  

	Divide_Integer(Integer_Class numerator, Integer_class denominator){
		//INLINED ASSEMBLY TO DO numerator/denominator
	}

To call this function:
	
	a = Divide_Integer(numerator=9, denominator=3);
	b = Divide_Integer(denominator=4, numerator=12);

The order of a stack based system is encoding the parameter for each
value.  When order is not used, the parameter to which to apply the
value must be stated explicitly.  This explicit mention is what you do
not like because it appears to waste space.  In case I was not clear:

EG, written vertically for comments

	a		//implied 'Name'
	b		//implied 'Age'
	c		//implied 'Spouse'
	MyFunction


I will ask about objects, in general.  Will Joy manipulate Objects
and/or structures?  Objects/Structures act very much like psets.  The
code to set a field does not contain the position of the field.  It is
the field name that indicates what memory location to change.  We all
could program objects assuming their fields are lists, compare:

EG Standard Method

	myobject=new MyObject();
	myobject.Name="Kyle"
	myobject.Age=26
	myobject.Spouse="Rhonda"

EG using only indexes

	myobject=new MyObject();
	myobject[0]="Kyle"		//implied Name="Kyle"
	myobject[1]=26			//implied Age=26
	myobject[2]="Rhonda"		//implied Spouse="Rhonda"

EG, better yet I can assume all parameters are to be set!

	new MyObject();
	"Kyle"			//implied Name="Kyle"
	26			//implied Age=26
	"Rhonda"		//implied Spouse="Rhonda"

WOW!  That makes for a difficult program to read!  There are so many
things I have to have in my head just to understand what the intent is.  

I have seen the similarity between setting the values of an object and
the parameters of a function.  To stay consistent I chose to alter the
function call to use psets instead.  What is Joy doing?



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