Intent

[iepos@tunes.org]

> >>The last one of these demonstrates that the stack names don't have to 
> >>name everything on the stack.
> 
> >I'm mostly worried about names between code modules, where most of the
> >trouble will crop up.  
> 
> I think that's best handled by a word defined for that purpose -- I won't
> burden the compiler down with more syntax.

There are a few thoughts I have relevant to this...

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.

One solution to this problem that would work for both kinds of systems
would be to set things up so that it is very easy for programmers
to construct their own libraries that wrap others. In a finished
Joy-like system, one might hope that there'd be several languages
of various styles (taking parameters in different orders) available
that programmers could choose from, although a programmer could also
easily construct his own language.

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.

I'm guessing that this is the quality that you call the "intentfulness"
of a system, the quality of not having to make many arbitrary decisions
when programming in it. If so, then I'd agree that it's a noble goal;
it's closely related to the goal of having programs be small in size.
Anyhow, it seems me like Joy meets this goal just as well (perhaps better)
than a pset approach would.

> >But if you name the variables, the system can labor to sort out which 
> >variable order makes most sense, based on data alignment issues,
> >frequency of argument use, difficulty of reordering at the caller, etc.
> [...]

Yes. In a Joy-like system, it is also possible for the system to
store parameters in an order other than the one literally given by
the programmer. However, in most cases, I suspect that the order
most natural to the programmer would coincide with the order most
natural to the system. But, in some cases this might not be so;
in particular, if one is dealing with libraries that have been wrapped
many times, then it would be a bad idea for the system to interpret
the ridiculous stack-juggling literally; fortunately, there are
fairly simple techniques that the system could use for simplifying
stack-juggling operations. A system might use "Combinatory Axioms"
like these:

   swap swap        -> 
   dup pop          ->
   swapd swap swapd -> swap swapd swap
   cons i           -> i
   cons pop         -> pop pop

This specific setup is not complete. I'm somewhat uncertain on whether
or not it is possible to construct schemes that have interesting
kinds of completeness. 

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

> >Your function 
> >implementation from four months ago will likely no longer maintain your
> >optimal ordering as you determined when you first wrote it, and woe be 
> >unto s/he who changes the order of his arguments after everyone else
> >is already using his/her code.
> [...]

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.

> >Jason Marshall
> 
> -Billy

- "iepos" (Brent Kerby)