Mon, 10 Apr 2000 09:03:38 -0700
From: Kyle Lahnakoski [mailto:firstname.lastname@example.org]
>> 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
>> 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
>> 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.
>up the issue of optimizing Joy programs; there had to be an
>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,
>of parameters, is a situation that both Joy and psets can not handle
>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
>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.