Am So., 24. Sept. 2023 um 11:33 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
> On 24 Sep 2023, at 11:14, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> > wrote: > > > In fact, the proposal of SRFI 245 deviates from the R6RS top-level > program semantics (and from the semantics I originally proposed for mixing > expressions and definitions) by not creating dummy definitions for > expressions appearing before variable definitions but by merging them into > the following variable definition. This, however, can easily make bindings > "complex" in the language of "Fixing Letrec (reloaded)", thwarting > important optimizations for many implementations. > > > > I strongly recommend returning to R6RS top-level program semantics > > > As far as I can tell, the point of Fixing Letrec (reloaded), as opposed to > the original Fixing Letrec paper, is that bindings becoming ‘complex’ isn’t > a problem unless they’re also recursive, so this does not change anything > about how optimizable things are compared to making each pre-definition > expression its own dummy variable. > First of all, definitions following expressions can be recursive (lambda) definitions. Secondly, even a non-recursive binding like (define foo (begin <expr> (lambda ...))) would be translated into (let ((foo (begin <expr> (lambda ...)))) ...), so the procedure wouldn't end up in a "fix" form. This would mean that the procedure eventually bound to foo would no longer "well-known" (barring a lot more sophisticated source optimizations), which would be very bad for efficiency.
