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

[btanksley@hifn.com]

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

>I hope you do not mind I broadcast this reply to the list.

No problem; hopefully we can all be enlightened.

>btanksley@hifn.com wrote:

>> But in a sense, this is a problem native to every system; the calling
>> conventions which make sense to me now won't make any sense 
>> to me later, and
>> that's all there is to it.

>Solving the parameter naming problem is trivial:  Give every parameter
>an Id, have each programmer associate a name, of their liking, to each
>parameter ID.  The "idiot programmer" can choose a name, you can choose
>to change it for your application.  Therefore, when I say name I really
>mean ID.  ID and name are the same unless we talk of poor naming
>problems. 

I'll treat them as interchangable in the future, then.  This makes sense.

This is only one of many calling convention questions that your scheme
addresses, of course; I'll concede that it does address it, although I have
my doubts as to the magnitude of the problem.

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

>> I don't understand these questions.  There is no structure 
>> stored anywhere
>> which is specific to calling MyFunction with those parameters.  The
>> parameters have no association with MyFunction until 
>> runtime, and even then
>> MyFunction is only a name; the important part is what's inside of
>> MyFunction.  The closest thing to a structure is the 
>> processor's "CALL __MyFunction" instruction.

>The parameters do have meaning.

This is an assumption you make because you're used to applicative languages.
Get rid of the assumption, get rid of the parameters, and you're rid of
_most_ of the meaning as well.  When there's no meaning, there's no need to
have extra information to describe that meaning, either.  A clean, costless
optimization.

>The meaning could be hidden in the
>implementation of the function though.

Or more accurately, the meaning is only carried by the semantics of the
function.  This is as it should be.  These semantics may be implied by the
name of the function (as with "+" or "drop"), or by the dictionary
documentation, or you may have to try to read the source code itself (a
terrible fate).

Creating parameter names does not add meaning, it only adds information.
(This is not in and of itself bad, as you know.)

>Where I would say a parameter is
>"age" you say "the nth parameter on the stack is what I store in object
>x".  Equivalent from the programs perspective, because it does the same
>thing with the parameter.

Sure, you can create as much meaning as you want -- but if it doesn't help
you read the program, perhaps you should stop doing it.  It's not my fault
that you're trying to drive nails with a screwdriver.

>> There's no need for a structure to store the interface; 
>> MyFunction itself
>> implies its own interface.  However, for convenience in 
>> typechecking, the
>> interface is often stored as an array of typeIDs (usually 32 
>> bits each).
>> The interface would ONLY be needed at compile time.

>Yes!! This paragraph is exactly what I am saying!  And I say that it is
>"hiding" intent.

No, there's no intent involved.  Or rather, the intent is expressed in other
and other places.

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

>> That's untrue -- you can not gain information by automatic 
>> translation.  The
>> information content is constant or decreasing (second law).  Joy code
>> translates directly to machine code, with no steps in between.

>I did not mean to say more information is added through conversion.  I
>am saying that the information required by the optimizer is made
>explicit during conversion.  Why not have the information in explicit
>form to begin with?  The optimization process is more expensive when
>parameter definitions are locked up on the code implementation.

Did you read my decription of my optimiser?  Do you know that my friend,
who's writing his own OS, has written three full register optimisers in four
days (much more sophisticated than my design)?  Yes, that includes all of
the design time.

BTW, the reason he wrote so many is that he prefers a prototype design
process; the first one worked, but he realised he could do more with a
different design.

>To summarize, from an optimizing perspective both types of code can be
>optimized equivalently.  But my issue is that Joy optimization may not
>be easy, actually quite difficult, maybe impossible because the intent
>is hidden in the code.

It's actually not.  You clipped my discussion of factorization, probably
because it made no sense to you.  Just as factorization makes little sense
in an applicative language, so also parameter specification makes no sense
in a concatenative language.

I'm not saying that your idea is bad -- although I think you haven't
considered some serious problems with it.  I'm just saying that it isn't as
superior to mine as you're claiming.  Consider that I, just like you, have
been educated almost entirely in applicative languages, but unlike you, I've
also studied concatenative languages.  I have a little more information on
which to base my choices.

Not an immense amount more info, of course.  Concatenative languages have
only recently been properly studied, so I _am_ taking a risk by following
them.  From what I've seen, though, and from the practical results achieved
in Forth, I'm quite confident in that risk.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy