[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

JINX reply on RECUR, DEFINE, ...

> Recursion for me (and most of the MIT-Scheme people) is a
> property of a process, not a feature of the particular syntax with
> which it was expressed.

We agree that the distinction between process and program is
fundamental.  But RECUR (Mitch's comment that RECURSE isn't English is
well taken) is at least expressive of the program (and has the
pedagogic virtue of emphasizing that program recursion expresses both
recursion and iteration of processes).  Local recursion (or iteration)
is too fundamental to be subsumed by LET, which expresses local
binding, *not* recursion (or iteration).  

We like Mitch's LABEL suggestion much better than named LET, but prefer

> SET! has too many connotations of side effects and I'm not willing
> to accept it as the primary definition mechanism.
> I don't view definition as a side effect.  Its interactive
> implementation involves one, in the same way that the interpreted
> implementation of LETREC involve side effects, only because we don't
> know how to do it any better...
> Purists in MIT-Scheme advocate for DEFINE to signal an error when
> attempting to redefine an already existing identifier in a given
> environment...

Your thorough justification of MIT's rationale is appreciated.  If
DEFINE could not be used to redefine existing bindings, we would have no
problem with it.  If the standard said that some systems may not permit
such redefinitions, we'd feel better about DEFINE being essential.
(Though most systems would allow redefinitions to ease reloading, as
you indicated.)

Your analogy with LETREC is not as close as you make it seem, for all
code within the scope of a LETREC is known at compile time, and the
same is not true for top level bindings.  (This is also the root of the
problem we have with the use of DEFINE as a substitute for LETREC.)
LETREC bindings are always new, never mutations of existing bindings.

> I'm willing to accept them in the standard as long as the CELL type
> is not required to be disjoint from PAIR (in the same way that
> CHARACTER is not required to be disjoint from STRING or INTEGER)...
> If they are adopted I suggest the following names:
> (MAKE-CELL VALUE) returns a CELL object with initial content VALUE.
> (CELL-CONTENT CELL) returns the content of cell CELL.
> (SET-CELL-CONTENT! CELL NEW-VALUE) makes the new content of CELL be

We don't mind lack of disjointness.  The names you propose are better
than none at all, but not our favorites (here we go again...); we use
them a lot (sometimes more than explicit cons cells) and would like
shorter names.  BOX and REF have the advantage that UNBOX and DEREF
make sense, and SET-{CELL|BOX|REF}! is enough for mutation.  We don't

We know everyone has had about enough of these name debates, but they have
served the useful purpose of clarifying our rationales.  We appreciate
Johnathan's restatement of the principle that if we can not agree after
making our rationales clear, then the standard should try to avoid
mentioning the points of contention.  This indicates that neither named
LET nor RECUR be mentioned.  DEFINE could stay, since that seems to be
the concensus, but it would be nice if its redefinition capability were