Namespace, Psets, Order, IDs, Joy (was: Intent)

[iepos@tunes.org]

Okay... Sorry for taking forever to reply to this.
Anyhow...

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

Okay. Yes, I see how that would be a solution. A programmer could
then rename the parameters to what he personally likes without
digging into the implementation. I'm guessing you'd want to be able
to rename other things also, other than parameter names; for instance,
you might want to be able to rename functions. You could probably
do that using the same technique.

Anyhow, a similar technique could be used in a Joy-like system,
so that if the system had a function named "divide" and the programmer
wanted to call it "quotient", it could be renamed with something
like this:

  [divide] "quotient" rename

In a similar way, the programmer could also change the order of a
function's parameters to the order he preferred. For instance, suppose
"divide" had taken the parameters in a order that seemed backwards
to the programmer; then he could have fixed it with:

  [swap divide] "quotient" rename

Or if he had still liked the name "divide" but just wanted the change
the order:

  [swap divide] "divide" rename

Anyway, this example just refers to a mythical Joy-like system;
this type of thing is not possible in the existing Joy.

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

I guess I'd agree with that. I like the idea of a system not keeping
source code around, but instead just keeping an internal version 
(possibly using something like your ID's instead of English-text
function names) that can be more easily manipulated; then, if a coder
wants to see a program, the system would generate the text on-the-fly
to match the coder's preferences, such as the names and order of
functions and pretty-printing styles, and the column width of his
terminal.

Of course, there might be some cases where the coder really does
want control over the exact layout of the code; for instance, this
may be the case if one is writing a program for some Obfuscated
Coding contest. In this case, some mechanism should still be provided
so that the textual source code can still be worked with.

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

Yes. But it does not entirely solve the problem. There is still the
question of how the subcomponents of the message will be structured.
For instance, suppose you are designing some function to put a
character on a text terminal. It needs to take an "x" and "y" coordinate,
plus a character to tell what to put there. Under your design, all
the parameters will be packed into one pset before being passed
to the function, but the question remaining is: will the "x" and "y"
be packed into a Point or something before being put into the
structure or will they just be put in the structure loose. It is
very much an arbitrary decision.

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

Hmm... I don't really see the original problem. I guess maybe you're
supposing that the apps used the function by reference, so-to-speak,
so that it would be expected that app be automatically updated if
the function changed. However, I would like the system much better
if the apps used the function by value, so that if one changes
the function, the app will just continue peacefully using the old
function.

I guess my confusion stems from talking about "changing the function";
to me it seems misleading to talk about a function changing. What
is probably really changing is the user's IDE, so that the same name
becomes mapped to a different function. Or, perhaps the stack has
changed, if one has popped one function off and pushed a different
one on. Anyhow, it makes sense to me that if a user modifies
a function by renaming that the change will only effect future
uses of the name and only by that one user, so that the system
need not go hunting around to change all the old apps.

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

- "iepos" (Brent Kerby)