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

[Kyle Lahnakoski]

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


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.  If you've done any work in a language with a
> heavy use of named parameters, you'll recognise that remembering what
> someone else chose to name a parameter is generally pretty hard, and often
> would result in you using a name which is inappropriate for your context.
> Ordering has the same problem, but because there's less information tied up
> in the ordering, it's often easier to remember.

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. 



> >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.  The meaning could be hidden in the
implementation of the function though.  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.

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

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


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.




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