[R6RS] cost of letrec* semantics for internal definitions
William D Clinger
will at ccs.neu.edu
Thu Feb 1 14:25:12 EST 2007
> is why some of us wished to make error-reporting requirments more
> stringent. With trepidation, I have gone along with a looser or no
> requirement in cases where we've had difficulty expressing the requirement
> or where there is perceived difficulty enforcing the requirement. I've
> also been swayed by the claim that by expressing a stringent requirement
> we are promoting some bogus programs to legitimate programs, but I
> realized belatedly that this is easily addressed by allowing such programs
> to be rejected before execution.
I don't understand. During yesterday's meeting of
Larceny developers, I explained what is wrong with
the 5.92 definition of the letrec* restriction, and
stated the letrec* restriction as I believe it should
be stated in the R6RS and as I suspect the project
editor intended it to be. That version of the letrec*
restriction is statically undecidable, just like the
R5RS letrec restriction.
How, then, could this matter be "easily addressed by
allowing such programs to be rejected before execution"?
Do you have a statically decidable version of the letrec*
restriction you'd like to propose for the R6RS?
More information about the R6RS