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...
> 
> But as the caller how do I know what order the function use the
> parameters?

Hmm... I'm starting to get a bit confused... 

If you're the caller, then you'll have to put the parameters in the
correct order (the order that the function requires them to come in),
and don't have to know what order the function will actually use them;
but, if you're designing a new function, and get to decide what order
the parameters come in, then it might be wise to make the ones that
will be used first be required top on the stack. Otherwise, you'll
end up having to use "swap", "dip", or something like it.

Hopefully that clears thing up...

> > 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.
> 
> Once you have structures to describe the interface to a function your
> size benefit might be gone.

This is probably true, to an extent.

> > > 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.
> 
> If I was to make a compiler, for fixed register processor, then I would
> HAVE to go convert Joy functions to the intermediate format to
> understand intent and make efficient code.  Somewhere, sometime, I will
> have to represent "Name is the first parameter" before I can go making
> the machine code to manipulate it.

Hmm... I don't see how that intermediate format would necessarily
be any easier to generate code for than the original Joy-like code.
Actually, the Joy-like code seems closer to the architecture of
most processors, so it seems like it would be more straightforward
to compile... but, who knows...

> >   2 3 Add_Integer 4 5 Add_Integer Multiply_Integer
> > 
> > It surely seems cleaner to me not having those "(", "=", ")", ",", ";"'s
> > cluttering things ...
> 
> You say clutter, I say loss of intent.

Hmm... I don't quite understand... are you saying that you also think
that the "(", "=", ")", ",", and ";"s are obscuring the program?
Or, are you saying the opposite, that they are essential to
the "intent" of the program and that taking them away destroys intent.

I'm still not sure what exactly you mean by "intent",
or why you find it such a valuable thing to have?
Does it make the system fast, small, or good in some other way?

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

- "iepos" (Brent Kerby)