Problems technical and procedural Daphne Preston-Kendal (02 Dec 2023 10:00 UTC)
Re: Problems technical and procedural John Cowan (02 Dec 2023 10:40 UTC)
Re: Problems technical and procedural Daphne Preston-Kendal (02 Dec 2023 11:04 UTC)
Re: Problems technical and procedural Arthur A. Gleckler (02 Dec 2023 16:01 UTC)
Re: Problems technical and procedural Per Bothner (02 Dec 2023 17:06 UTC)
Re: Problems technical and procedural Marc Nieper-Wißkirchen (02 Dec 2023 17:18 UTC)
Re: Problems technical and procedural Arthur A. Gleckler (02 Dec 2023 17:33 UTC)
Re: Problems technical and procedural Marc Nieper-Wißkirchen (02 Dec 2023 17:23 UTC)
Re: Problems technical and procedural Arthur A. Gleckler (02 Dec 2023 17:37 UTC)
Re: Problems technical and procedural Marc Nieper-Wißkirchen (04 Dec 2023 08:50 UTC)
Re: Problems technical and procedural Marc Nieper-Wißkirchen (02 Dec 2023 10:43 UTC)
Re: Problems technical and procedural Sergei Egorov (02 Dec 2023 10:45 UTC)
Re: Problems technical and procedural Daphne Preston-Kendal (02 Dec 2023 11:11 UTC)
(missing)
Re: Problems technical and procedural Daphne Preston-Kendal (02 Dec 2023 17:46 UTC)

Re: Problems technical and procedural Daphne Preston-Kendal 02 Dec 2023 11:11 UTC

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.

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