Re: Naming BABY-DOE

[Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>]

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.