Lists, Tables, Psets

[iepos@tunes.org]

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

I am; it is most natural to push first the things that will be used
last. But, this is just an observation about Joy; I'm not saying it
applies to other kinds of systems...

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

Hmm... I suppose you are talking about the implementation now, right?
You're asking where the parameters are stored, right? The parameters
are stored on the stack; in the current Joy implementation, the
stack is implemented as a linked list... It could probably be
implemented much more efficiently using some sort of array.

> What is the data structure used to define the interface for MyFunction?

Hmm... In the current Joy system, one does not define the interface
for programs, but only defines the programs themselves. There is room
for improvement in this area, I think; it would be nice
if the system allowed one to specify certain "interface" properties
of programs (which were checked by the system to ensure that they
really did have those properties), for instance the types of things
they expect and leave on the stack, and whether the program is pure
(without side effects) or not.

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

Hmm... Joy code is itself very nice to reason about; I don't think
there's a need to use an intermediate format.

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

Well, I'd surely be happy to take a look at what you can find;
it'd be nice if it was available through the Internet.

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

It looks like "(2+3) * (4+5)" would not even fit on a line, then...
It might look something like this, I guess

  n = Multiply_Integer(num_a=Add_Integer(num_a=2,num_b=3),
                       num_b=Add_integer(num_a=4,num_b=5));

This is big compared to what it would look like in a Joy-like system,
even if one used the big names:

  2 3 Add_Integer 4 5 Add_Integer Multiply_Integer

It surely seems cleaner to me not having those "(", "=", ")", ",", ";"'s
cluttering things ...
 
> I will ask about objects, in general.  Will Joy manipulate Objects
> and/or structures?  Objects/Structures act very much like psets.  

As far as I know, the current Joy implementation has no support
for structures with named elements; instead one would use
lists. 

It looks like Joy has entirely avoided the paradigm you advocate,
of using identifiers to name the elements of structures.

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

In a Joy-like system, one would indeed use lists; the Joy analogue
of the two programs given is:

  ["Kyle" 26 "Rhonda"]

See how much shorter it is :-)

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

No... You just have to remember the Order... this is not really much
worse than having to remember the names "Name", "Age", and "Spouse",
except that those names have English significance that help one
remember. 

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

Well... a similar sort of thing happens in Joy, in that setting
the values of a list (or otherwise doing things to a list) is similar
to doing things just to the stack, although distinct. "concat" 
(which concatenates two programs) is the relation... 

While you would use "swap" to swap the top two things on
the stack, you would use "[swap] concat" to swap the first two things
of a list. Similarly, to duplicate the last thing on a list, you'd
do "[dup] concat".

Actually, this sort of thing doesn't quite work perfectly in the
current Joy system. Anyhow, this probably seems weird. I recommend
taking a look at the documentation for Joy. It is really an
amazing system, even though it's not too efficiently implemented
right now.

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

- "iepos" (Brent Kerby)