[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LETREC (REC)
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.