Intent

[Jason Marshall]

Firstly, I appologize for the poor formatting.  I have been beset by 
not one, but two vile linewrappers.  I have to just remember to relax 
and let the linebreaks fall where they will, instead of inserting them 
myself, as a programmer is prone to do :)

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

Yes, that's it almost exactly.  "like" may not be the exact word I'd 
have picked, but about the fourth time something does other than I 
wanted it to do, I stop liking it, so that will suffice.

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

But this issue can be resolved at compile time.  Ordering issues have 
to be resolved at debug time, or are missed altogether.

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

All procedural, object, and most of the functional languages I know 
name their parameters, but outside of code assistance tools, these 
names are generally only externally visible in the documentation, if 
there.  While appropriate tools can counter some of the arguments for 
parameter sets, the core static evaluation issue still remains, and 
that's the one I feel most strongly about.  And in fact, such a tool 
can take away the added headache of setting up a well-known method 
signature, as it can create a 'blank' call for you with the fields you 
want, making it harder to forget the naming convention the original 
developer used.

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

This is true.  I'm not sure how one would go about 'fixing' this.

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

It seems that several folk have accepted as truth that compactness is 
optimal.  I don't agree.  Humans and computers do not, and for the 
forseeable future will not, think alike.  So what is most concise for 
the computer may not be the most elegant statement for Joe Programmer.  
Maybe for you, maybe for me, but probably not for Joe.  And Joe and his 
boss make or break the language.  And some days, I don't particularly 
care to show off my mental prowess just to get the basic aspects of my 
job done.  I like to reserve the Extreme Brainpower (tm) for special 
occasions, like architecture meetings or figuring out why my IDE is 
crashing nonstop this week (okay, I don't enjoy the latter, but I get 
to do it too often).

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

Okay, I'll buy that.  So, to sum up:  From an optimization standpoint, 
the transformation effort is of equal magnitude.  Give a constant here, 
and take one there.

>> >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 here, if you change the names, you change the method signature.  If 
I add or remove an argument, have I not constructed a different 
signature?  So we've replaced order with names as a defining aspect of 
a method signature.  But how often do you change parameter names 
without changing the intent of the method?  I've done this perhaps a 
dozen times.  I'm always adding or removing parameters, or running into 
libraries where two developers (or one inattentive one) used a 
particular ordering of arguments on one method, but on a logically 
similar one, switched them.  And don't get me started with how X 
coordinate is first in cartesian coordinates, but column index is 
second in tabular forms.  I mess that up about every forth time I have 
to create a table to view data.

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

Local copies of libraries.  Now there's a whole other can of worms.

-Jason