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