Intent

[btanksley@hifn.com]

From: iepos@tunes.org [mailto:iepos@tunes.org]

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

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

This was basically what I was thinking -- and it was my understanding that
it's also what he had intended for psets.

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

Actually, interestingly enough, I would say that the intentfulness of a
system is increased by being able to make arbitrary decisions in it.  For an
example of a low-intentful programming language, consider Fortran.  There,
you don't get to decide what letter your variable names start with -- the
language has decided for you.  Your code has _lost_ some expressiveness.

He's pointing out that in Joy, you don't have the liberty of using parameter
order to communicate meaning, because it has another use in the language.
This is a true accusation, although I disagree that it matters -- he's
already realised that meaning is not effectively communicated by ordering.

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

You're right; the only thing the system could do to change this it to change
the order of execution.  Fortunately, this is not hard.

Oh, by the way, that's COMPLETELY othogonal to naming the parameters, or
assigning names to stack items, or whatever you're suggesting by saying "if
you name the variables."  Variable names would allow certain types of static
error checking and would be useful in debugging, but would provide ZERO help
in optimizing.

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

>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 interesting question, on which I'm afraid I haven't been much help.

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

No; he's not using any names of any kind.  He's simply tagging registers by
their stack position, and updating the tags when he encounters
stack-affecting instructions.  Most stack juggling operations emit no code;
they merely change the bookkeeping.

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

That's a good point, yes.  I didn't think of that.

>- "iepos" (Brent Kerby)

-Billy