> On Dec 2, 2023, at 5:12 AM, Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
> On 2 Dec 2023, at 11:45, Sergei Egorov <xxxxxx@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.