Intent

[btanksley@hifn.com]

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

>iepos@tunes.org wrote:

>> If I understand, one of Jason's main complaints about 
>> Joy-like systems
>> is that bad things will happen if one programmer writes a library
>> and then another programmer goes to use it and the functions don't
>> take the parameters in the order he'd prefer. I do see how this could
>> be a bit of a problem... However, it seems to me like the 
>> "pset" approach
>> has a very similar problem: one programmer might use another 
>> programmer's
>> library and the _names_ of the parameters may not be what 
>> he'd prefer.
>> Just as in a Joy-like system one must choose an arbitrary order for
>> the parameters, in a pset system one must choose arbitrary names
>> for the parameters.

>I have already mentioned that the name-change problem is simply solved
>by giving each programmer a parameterID-to-parameterName mapping.

Agreed.  And this is the same solution you can use with a concatenative
language -- except instead of having to add a new concept to the language,
"parameter name mapping", you simply redefine the function you want and
juggle its parameters.

>> An alternative technique for simplifying stack-juggling operations
>> involves (at compile-time) making up some labels for stack
>> items and tracing what would happen to them when the program was run;
>> then, the compiler rewrites the whole program using the 
>> stack-juggling
>> that seems best to it. This approach is more along the lines of what
>> Billy's friend is doing, I think...

>The "labels" you refer to are equivalent to parameterIDs.

No, they're not -- he's incorrect.  Parameter names contribute _nothing_ to
a Joy-style program.  The only reason to use them is to provide the ability
to errorcheck what a programmer thinks is on the stack.

>I 
>had brought
>up the issue of optimizing Joy programs; there had to be an 
>intermediate
>interpretation of the Joy program before it can be optimized.  The
>"labels" approach described above is exactly that.  I do admit that
>there could be a method of optimization, maybe one that uses code
>pattern mappings, to optimize without an intermediate stage. 

Nope; the labels contribute NOTHING to optimization.  There is no
intermediate form of any kind.  OTOH, with your system there IS an
intermediate form; unless I miss my guess, you're converting this stuff into
a set of tables containing IDs, and doing lookups on those tables.

>> Again, a similar problem happens in your style of system. A person
>> who writes a library might go back and change the names of some of
>> the parameters, and woe be unto everyone else who was using the
>> old names. But actually, I don't see the problem quite happening this
>> way; if I was "everyone else", then I would have made a 
>> local copy of the
>> library instead of relying on the writer not to change it; 
>> then I would
>> know that the parameter orders (or names) are not going to change.

>Changing the interface for a function; adding removing, 
>changing meaning
>of parameters, is a situation that both Joy and psets can not handle
>well.

Okay.

>This is a different type of problem than just renaming, or
>changing parameter order.

Fortunately, both of those things are considered bad ideas -- so much so,
than in your system it's impossible for the author to change parameter
order.

>This problem is about defining totally new
>interface/functionality.  The only solution I envision is to have the
>re-implementor create a mapping from the old function interface to the
>new one.  The Tunes-like system can then go to all apps that 
>use the old
>interface and alter them for the new one.

That's reasonable.  You won't even need a Tunes-like system; all you need is
a tiny bit of inlining power; the system will notice that the call being
made is short and consists mainly of stack juggles and constants; it'll slam
all of that stuff into the optimiser, and it'll probably not even have to
emit any code (it'll just change the code it was already about to emit).

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy