Lists, Tables, Psets

[btanksley@hifn.com]

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

>iepos@tunes.org wrote:

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

The same way you know what the 'idiot programmer' who wrote the function
you're calling happens to have chosen to name his parameters.  You seem to
be making the assumption that the programmer will have chosen names that
make sense to you in the context you're using now.  False assumption.

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

A meaningless statement.  The programs themselves specify their own
interface; any type specifications which the user might give are useful only
to allow the compiler to verify that they match the type of the actual
function.

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

No, you wouldn't.  "Name" is a slot in the object, not a parameter.  The
first thing we do in the initialization function is set the slot "Name" to
the value of the first stack item.

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

I agree with your accidental meaning.  Clutter obscures intent.

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

>In DBOS (uses psets), the mapping from field name to field must be done
>in the head.

Correct.  You also have to map out any paramater changes (if such were
possible), as well as the parameter origination (where it was declared).

>Joy requires the a mapping from element to field AND the
>order of the elements.

Um...  No...  At most, assuming that we're talking about a (hypothetical)
Joy function which initializes an object (Joy doesn't support objects as
such, so this is very hypothetical), you have to remember which parameter
(in order) initializes which field.  That's only a single order mapping.

But then I'm not sure what you mean by introducing the new word, "element".

>Consider the question "what is the 9th 
>letter of the alphabet?"  You have the mapping from 
>glyphs-to-letters stored in your head, but you store the order 
>of the alphabet separately; having to
>follow the "linked list in your head until you get to the 9th letter. 
>If you manage to remember the absolute position of every parameter then
>you are maintaining a map from digit to position, and then to field in
>your head.  The same number of maps, but different arrangement.

This is one reason why Forth programmers prefer to keep their functions with
three or fewer parameters.  The human mind can instantly recognise at most
three objects; any more, and you have to form them into a list for
sequential processing.  (More than seven objects, and you have to use
long-term memory to hold the items.)  Now, long-term memory isn't a bad way
to do things, but even if you're personally familiar with the peg system (a
memory tool), you'd best not assume that the person maintaining your program
has the same pegs all set up :-).

So yes, huge parameter lists are a problem; but I'm confident (on the basis
of experience) that you'll find that large parameter lists are ALWAYS a
problem, whether named or unnamed.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy