LETREC (REC)

[Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>]

				       Certainly when binding non-procedures,
    the use of LETREC is ugly and ill-defined

Unfortunately it is not ill defined.  A simple "operational"
description (like the one in the currentl version of RRRS) describes
what is legal and what is not.  I view this operational description as
a crock, and the only way that I can see to restrict the use of LETREC
to reasonable cases is to "over-restrict" it.

The problem is that it is hard to decide when to stop.  The boundary
is fuzzy, but I'd be much happier with the restriction than with the
current semantics.

    Here foo is being bound to a non-lambda expression one of whose arguments
    is a lambda-expression which calls foo.  I think this is perfectly reasonable,
    as long as the recursive reference only occurs within defining forms like lambda;
    and if it doesn't there's already an error to handle the case (unbound identifier).

If we start along these lines, what happens to macros that expand into
lambdas?  What if we use the definition of begin in RABBIT?
Constraining it to "defining" forms is not enough, the lambda
expressions must not be invoked until after all the expressions have
been evaluated, but this is too complicated.

Note that the error is not unbound variable.  The variable is bound,
since the expressions are evaluated in an environment where the names
are bound.  At best it is unassigned, but this implies that there are
side effects going on, which I don't like.