Intent

[Kyle Lahnakoski]

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.  The
initial programmer can call the parameter "foo".  The machine maps "foo"
to 386445.  A second programer wants to use the function, sees "foo" and
does not like it.  Change the name of "foo" to "bar" and the machine
then has a map from "bar" to 386445.  The maps are dependent of what
programmer is viewing the code.  The initial programmer can change the
name later in development, but the ID of that parameter (386445) will
never change: no impact on the the second programmer.

So, I will show the structures needed to store these mappings.  I will
use table schemas, because I am most familiar with them.  You can easily
see there is mapping from this view to any OO implementation.


PROGRAMMER
  ID   |   NAME
--------------
  25   |   Kyle
  45   |   Mike


TABLE_TRACK_MAPPINGS
ParameterID | ProgrammerID | Name
---------------------------------
   386445   |     25       | Kyle
   386445   |     45       | Mike



This brings up a question of mine concerning namespaces.  There is quite
a lot of talk of namespaces.  I am of the belief that namespaces belong
to the personal compiler/IDE of the programmer, not the system.  The
system just manages unambiguous ID values, the compiler converts
intended human meaning (source code) into pure ID communication.  For
that reason the semantics/syntax of the code used to communicate with a
Tunes-like system is irrelevant.  I created "ObjectCode" knowing that it
will have a short life span.  ObjectCode only has the minimal
expressiveness required for a reflective system.

Can someone tell me what others are seeing when they speak of
namespaces.  What issues are namespaces solving that the above mapping
idea does not?


> Anyhow, parameter-order is not the only seemingly-arbitrary thing
> that one must decide when making libraries. Another thing one must
> decide is the structure of how things are passed; will one pass
> several parameters in unwrapped form, or will one instead make
> a list ("object", "structure", or whatever) containing them and just pass
> that? Again, the pset approach has the same type of problem here
> as Joy.

The solution I have is to ALWAYS pack the parameters into a message. 
Commonly, object slots/fields are accessed like psets (a.setName("Kyle")
OR a.Name="Kyle).  Messages are objects, therefore uniformity says that
messages are populated like psets.  This appears quite clean to me.


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



> 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.  This is a different type of problem than just renaming, or
changing 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.






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