Fri, 07 Apr 2000 23:09:00 PDT
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
>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
>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
>that? Again, the pset approach has the same type of problem here
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
>of a system, the quality of not having to make many arbitrary
>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
>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
>> >variable order makes most sense, based on data alignment issues,
>> >frequency of argument use, difficulty of reordering at the caller,
>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
>A system might use "Combinatory Axioms"
> 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
>> >optimal ordering as you determined when you first wrote it, and woe
>> >unto s/he who changes the order of his arguments after everyone
>> >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
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
>library instead of relying on the writer not to change it; then I
>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.