Am Sa., 2. Dez. 2023 um 17:05 Uhr schrieb Sergei Egorov <e...@acm.org>:
> > On Dec 2, 2023, at 5:12 AM, Daphne Preston-Kendal <d...@nonceword.org> > wrote: > > On 2 Dec 2023, at 11:45, Sergei Egorov <e...@acm.org> wrote: > >>> • It doesn’t map cleanly onto letrec*; > >> Bodies allow various kinds of definitions, including define-syntax, so > mapping is never as clean as it used to be. This SRFI is as clean as R7RS > it translates to. In fact, its semantics is defined more precisely this way. > > This is exactly the problem with R6RS compatibility in this proposal: > bodies with internal definitions become letrec* specifically *after* all > macros have been expanded, i.e. after define-syntax has gone away. > Could you please elaborate? As I see it, the difference is not in whether > the body eventually becomes letrec* or not (it is letrec* in both > proposals), but whether, after all macros are expanded, it becomes a single > letrec* or possibly multiple nested letrec*s. > If more than one scope is introduced, it should be made explicit (by a form introducing the scope and which causes an indentation). SRFI 251 can create any number of scopes (nested letrec*s) without these being lexically apparent. > >>> • It’s compatible neither with the R6RS expansion order for all > bodies, nor with the R6RS top-level program body semantics; > >> It targets R7RS, and mentions this fact specifically. > > R7RS Large’s current goal is specifically to reunite R7RS small with > R6RS. As such, this proposal would be out of scope for R7RS Large. > It could be the case (it's hard for me to tell), but as nothing in SRFI > process as I understand it limits it to the scope of any particular future > standard. > One may draw the conclusion that neither SRFI 245 nor SRFI 251 are ready for standardization if there is such a fundamental disagreement in the community. > > > (The fact there is no existing implementation would also lead, at least, > to a deferral of definitive acceptance of this proposal until three major > Scheme implementations have taken it up.) > This would be a strong argument if Scheme evolution was driven exclusively > by what major implementations do. I'd like to believe it isn't so, and R7RS > Small is a proof to that. > > >>> • If you insert a new line between definitions, the scoping rules > suddenly change. > >>> I can elaborate on these if needed. > >> You mean new command? Yes, insertion of a command changes the scope of > subsequent definition (which may or may not affect the overall meaning), > but the insertion is local and easy to spot as you read the code. SRFI-245 > suffers from its own nonlocal problem -- you cannot determine the meaning > of any identifier until you scan the whole body to the end. Bodies can be > long. > > The insertion is not necessarily easy to spot given the possibility that > forms within a body include macro uses which could expand into definitions, > expressions, or a mix of the two. > > So far, people preferred to name definition-producing macros in such a way > that they are easy to spot, i.e. define-xxx. If they don't, it will make > the code hard to understand, no matter which of the two proposals is > chosen. I believe SRFI-245 is even more vulnerable to this sort of problems > because of nonlocality of its effects. > One motivation for allowing definitions following expressions is to allow, say, inserting type-checking expressions or logging expressions between internal definitions. In SRFI 245, this won't change the global semantics of the procedure body; with SRFI 251, it would (and it would not be visibly apparent.) It is not about inserting definitions but inserting non-definitions that should not suddenly create a new scope.
