[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Naming BABY-DOE
Retrying failed mail...
Date: Fri, 29 Sep 89 16:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Naming BABY-DOE
To: ramsdell@linus.mitre.org
cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: <8909291042.AA17204@huxley.mitre.org>
Message-ID: <19890929202000.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 29 Sep 89 06:42:04 EDT
From: ramsdell@linus.mitre.org
>> From: Alan Bawden <bawden@parc.xerox.com>
>> I presume we have all agreed that the order of arguments to BABY-DOE is
>> (BABY-DOE <generator> <receiver>)? That is, you are certain that nobody
>> thinks that certain names only make sense given certain argument orders?
I don't recall anyone supporting is call for the reverse argument
order, so I assume the one you gave is it. Of course, I could have
lost some mail....
Depending on the function name, I support different argument orders.
For example,
(APPLY-TO-VALUES <receiver> <generator>)
(CALL-WITH-VALUES <receiver> <generator>)
but
(CONTINUING <generator> <receiver>)
(CALL-WITH-CONTINUATION <generator> <receiver>)
Note that I find no inconsistency in having one CALL-xxx thing take the
arguments in one order and another CALL-xxx thing take the arguments in
the other order. The basis of my preference is the following: APPLY
and CALL are verbs that take a direct object and an indirect object
(introduced by "with" or "to"). e.g., in the case of CALL-WITH-VALUES,
the direct object is the thing to be called and the indirect object
(introduced by "with") is the thing which generates the values. On the
other hand, CALL-WITH-CONTINUATION takes a direct object of a thing to
call and an indirect object (introduced by "with") of a continuation to
use.
I did a study of functions in the Lisp Machine system which have -WITH-
in their name. There are a zillion of them, and no explicit rules about
argument order, but statistically observed rules which suggest a linguistic
guiding principle consistent with that I cited in the previous paragraph.
I began to write up a more detailed analysis of the observed uses a while
back but decided that probably wouldn't care about the detail, so I filed
it away.
Btw, I don't like APPLY-VALUES because it's ambiguous whether "values"
is modifying arg1 as an adjective or whether there's an implicit "with"
or "to". A reasonable case can be made for either of
(APPLY-VALUES <generator> <receiver>)
or (APPLY-VALUES <receiver> <generator>)
which is conceptually dangerous for a function which takes two functions
as an argument--since the arguments sometimes can't be statically
(or even dynamically) detected to be in the wrong order.
Getting back to the original question, though...
My preference for the continuation invoker drives my preferences for the
other things, so it's a two-level sort...
1. Strong preference for CONTINUE to be the invoker. This is because it
is count-neutral, because it is not imperative, and because it suggests
a useful relationship with "continuations". I'm less fussy about
the name of the linker, but here is the breakdown on my current
thoughts anyway...
a. Moderately strong preference for CONTINUING (mostly because it
doesn't seem to confuse people in some of the ways that
CALL-WITH-CONTINUATION apparently does--also, it's short, which
CALL/CC fans must admit is a virtue.)
Example: (CONTINUING (LAMBDA () (CONTINUE 1 2)) CONS)
b. Slight lesser preference for COMPOSE-CONTINUATION.
Example: (COMPOSE-CONTINUATION CONS (LAMBDA () (CONTINUE 1 2)))
I'd also be willing to do some currying here.
((COMPOSE-CONTINUATION CONS) (LAMBDA () (CONTINUE 1 2)))
c. Slight lesser preference for CALL-WITH-CONTINUATION.
Example: (CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
If you're the sort to care about the possibility of extra args,
there's an issue here about whether if more arguments are added
they should be more continuations or just arguments to the first
function. My study of the LispM data suggests that people write
(frob-with-something frobee the-something frob-arg1 frob-arg2...)
e.g.,
(cook-with-recipe 'bread (recipe-of mom) :stove-type :electric)
The issue is whether you want to trade the occassional ease of
(CALL-WITH-CONTINUATION fn cont1 cont2 ...)
over
(CALL-WITH-CONTINUATION
(CALL-WITH-CONTINUATION fn cont1) con2)
for the ease of
(CALL-WITH-CONTINUATION CONTINUE CONS 1 2)
over
(CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
This may be all a red-herring.
2. Lesser but still noticeable preference for YIELD, primarily because
it doesn't have the problem of plural which VALUES (below) has.
The main problem here is that there is no similarly nice word which
describes the receipt of yielded values. I'm open to suggestions, though.
3. I dislike VALUES, but not as much as some other things. It's the "S" in
"VALUES" that really makes me dislike it. The fact that sometimes you
want to say VALUE and other times VALUES. But if VALUES -were- chosen, then
my preference is:
a. WITH-VALUES (mostly for symmetry with other WITH forms already in
Scheme). For better or worse, the argument order is also dictated
by those functions.
b. CALL-WITH-VALUES, APPLY-TO-VALUES, etc. are less good, but not terrible.
c. RECEIVE-VALUES and APPLY-VALUES are tolerable but not desireable, but
both suffer from the problem of no unique, intuitively dictated argument
order. If there were another like APPLY-LIST, APPLY-VECTOR, or something
in the language, it would improve the case for the name APPLY-VALUES--but
even then it would be weird because `values' is not a datatype like LIST
or VECTOR.
4. Strong dislike for things like RETURN and EXIT which suggest imperative
transfer of control. I want an operator which suggests a more passive
transfer of information.
Sorry about being so long-winded. I'm hoping this data will give you an
idea of how I think about all this and how I'm likely to receive new
suggestions or to react to some particular compromise.