Lists, Tables, Psets

[btanksley@hifn.com]

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

>iepos@tunes.org wrote:

>> > But as the caller how do I know what order the function use the
>> > parameters?

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

>To have the caller put the parameters in the right order may require
>many "swaps" and "dips" by it.

Certainly not _many_, but it may require some.  It's more likely that it'll
require the caller to rethink how he's writing the program -- it's better to
do things efficiently and require less juggling.  It's also clearer.

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

>The latter: the "(", "=", ")", ",", and ";" increase readability.

Well, they don't.  They clutter it not only with their presence, but also by
changing the order of execution.  A concatenative program is evaluated
purely left to right, no exceptions; if you add application, though, as your
language does, you have to evaluate and execute the parameters before you
evaluate and execute the function which is going to use them -- even though
the parameters appear _after_ the function whose evaluation they _precede_.

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

>Intent is the ease at which a program can be reverse engineered,
>preferably by a machine.

That's a reasonable definition.  Read some of the documentation on Joy; I
think you'll be impressed.

>Intent is good because of the reverse engineer aspect.  There must be a
>reason why people prefer higher level languages.  The average human
>being is not a memory machine.  I know a couple of people that have
>incredible memories, and maybe Joy is for them.

Incredible prejudice.

>But I would never
>remember parameter order, especially if that order is dependent on
>implementation.  Most of my time will be spent looking up parameter
>order in the help file, again and again.

A fair statement, and I honestly have to agree.  I would also spend my time
that way, unless of course there were three or fewer parameters per function
-- this is, in fact, the case in Forth, and would be my goal in any program
I design.

If there were only two parameters per word, I would still be spending most
of my time looking up function definitions/documentation, but it would be to
discover the semantics of the functions, not the parameter order or what
particular mispellings the library author used.

>In C or Java, the parameters
>have order, but at least a fairly consistent and logical order.

Right.

fprintf(file, string, ...)
fgets(string,number,file)

Um...  Wrong.  ;-)

>I propose the next step, remove order, and use parameter names.  
>When I call a function I find it much easier to remember the 
>parameters required than recalling order too.

Have you used any of the existing languages where this is used to a large
degree?  They do exist, and most people use them only when absolutely
necessary.  The problem, as I've mentioned, is that the parameter names are
not gueranteed to make any sense in your situation, and most commonly only
make sense from the situation the original author was in -- which _usually_
has almost nothing to do with the purpose of the routine.

>Maybe I am making a point on human interfacing.  Our memories are
>associative; given a trigger, the associated thought is easy 
>to recall. 
>The association between parameter name and the parameter 
>concept is very easy to recall.

Very true, and apropos to the discussion.  The explicitly associative nature
of your system is a big plus in its favor.  I can't claim anything like it.

>Communication with a human can be more efficient of
>there is redundancy in the communication.

Also true, but less relevant.  Joy code can have as much redundancy, just in
different places.  The usual way to make your code have enough redundancy is
to factor it well; this, in turn, makes the definitions very short and calls
very frequent.  And making calls frequent is the ideal recipie to bring an
applicative language to its knees, since a new call frame has to be
allocated for each call.  (A concatenative program literally only has to
push a return address and jump for a call.)

>Like I said before, once you have
>all the data structures in place that describe the structure of a Joy
>program you will see that it is no better off than what I propose.

I don't know what you're saying -- Joy is already running, and we're
describing it.  Forth is another powerful, commonly used language;
Postscript is less powerful, but still VERY commonly used.

>We
>both have the same amount of information in a particular program.  I
>have normalized the database containing these structures, so 
>there is no
>redundancy; my code is as small as it can get, for the information it
>contains.

And I don't have the structures.  At all.  Nor do ANY of my instructions
have parameters, so they take less storage space.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy