> 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.
>>> • 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. > (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.
