Am So., 24. Sept. 2023 um 13:27 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
> 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. > And this is why I insist that it is important to deliver a sample implementation with this SRFI. And that sample implementation should prove that this optimization is "trivially" possible in optimizing compilers like, say, Chez or Loko (which use the "Fixing letrec (reloaded)" algorithm). Without such a demonstration, it is too rash to write such semantics in a new Scheme standard. > 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. > Better be safe and conservative; one can always give the programmer more freedom later, but going the other way is not possible (in a backwards-compatible sense). Marc
