On 2 Dec 2023, at 16:32, 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.

I don’t understand your question either, which suggests that we’re talking at cross purposes here.

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

Since you positioned this as a competitor to SRFI 245, which itself is intended as a contribution to the R7RS Large process, I naturally assumed you also intended this SRFI to be considered for R7RS Large.

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

Macro-generated definitions can also be implementation details of a macro, however (binding names not visible outside of the expansion itself), in which case a define- name would not necessarily be used.

Such macros which actually mix hidden definitions with expressions in their expansion are admittedly currently rare (because they can only be used once in a body under the R5RS/R6RS rules), but would likely become more common in any SRFI 245/251 like situation.

Daphne