LETREC (REC)

[Ken Haase <KWH@AI.AI.MIT.EDU>]

    Date: 1 Apr 1986  09:47 EST (Tue)
    From: Bill Rozas <JINX%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
    To:   Ken Haase <KWH at AI.AI.MIT.EDU>
    cc:   RRRS-AUTHORS at MC.LCS.MIT.EDU
    Re:   LETREC (REC)

    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 this particular over restriction really diminishes
the power of the language; no clever macrology (in the current RRRS)
is going to allow general higher order functions to generate recursive
functions.  (By general, I mean higher order functions which don't
specifically expect to generate recursive functions).

    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.

I meant unassigned.  I think that in any implementation-oriented
explanation, you may have to resort to side effects to explain
what is going on.   Even if you characterize LETREC with delays,
it seems to me that you will still have an understood side-effect 
lurking inside of the delay.