(comment at the very end) On Dec 2, 2023, at 11:02 AM, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> wrote:
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.
=======
There could be other, more explicit ways to allow commands between definitions without introduction of new scope, e.g. extending 'define' to allow forms like (define () <command>) or even (define <command>) to mean/expand into whatever (define-values () (begin <command> (values)) means/expands to.
The idea behind this proposal is that seeing another groups of definitions after commands in body would be naturally expected to start a nested scope, as it does in many languages, starting from C to recent crop of functional languages.
|
