You may be correct that the ‘fixing letrec reloaded’ algorithm, unmodified, 
might have these issues. However, a compiler can trivially recognize an 
optimization of (let ((foo (begin <expr> (lambda ...)))) …) to make foo be 
‘well known’ after the transformation of letrec* to let, fix, and set! is 
completed.

I don’t want to compromise the semantics (I don’t see a reason to forbid 
returning multiple times to the continuation of an expression, as long as any 
following definition is not reached and completely re-evaluated) for an 
optimization which seems possible anyway — and which I think would not be 
needed in the vast majority of use cases of SRFI 245 anyway.


Daphne

Reply via email to