[R6RS] cost of letrec* semantics for internal definitions

[William D Clinger]

Kent wrote:

> ....This
> 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?

Will