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.

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

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

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

As for the issue of ‘non-local’ reference, see my response to John Cowan’s 
parable of Simpleton and Hardcase here: 
<https://wiki.dpk.io/use-before-definition.html>
The short version is that it’s not our job as language designers to prevent 
people writing unreadable code; moreover, the order I explain things to a 
computer doesn’t at all have to reflect the order I explain them to a human 
reading the same code, because the human can read comments and other 
documentation, which the computer cannot.


Daphne

Reply via email to