|
Re: 251 vs. 245
Sergei Egorov
(01 Dec 2023 23:43 UTC)
|
|
Re: 251 vs. 245
Per Bothner
(02 Dec 2023 01:54 UTC)
|
|
Re: Re: 251 vs. 245
Sergei Egorov
(02 Dec 2023 02:23 UTC)
|
|
Re: Re: 251 vs. 245
Sergei Egorov
(02 Dec 2023 02:28 UTC)
|
|
Re: 251 vs. 245
Per Bothner
(02 Dec 2023 06:11 UTC)
|
|
Re: Re: 251 vs. 245
Sergei Egorov
(02 Dec 2023 07:12 UTC)
|
|
Re: 251 vs. 245
Daphne Preston-Kendal
(02 Dec 2023 09:54 UTC)
|
|
Re: 251 vs. 245
Vladimir Nikishkin
(02 Dec 2023 12:30 UTC)
|
|
Re: 251 vs. 245
Marc Nieper-Wißkirchen
(02 Dec 2023 12:33 UTC)
|
|
Re : Re: 251 vs. 245
Amirouche
(04 Dec 2023 08:36 UTC)
|
|
Re: Re : Re: 251 vs. 245
Marc Nieper-Wißkirchen
(04 Dec 2023 08:42 UTC)
|
|
Re : Re: Re : Re: 251 vs. 245
Amirouche
(04 Dec 2023 09:27 UTC)
|
|
Re: 251 vs. 245 Daphne Preston-Kendal (04 Dec 2023 09:57 UTC)
|
|
Re: Re : Re: 251 vs. 245
Vladimir Nikishkin
(04 Dec 2023 09:50 UTC)
|
|
Re: 251 vs. 245
Daphne Preston-Kendal
(04 Dec 2023 10:24 UTC)
|
|
Re: 251 vs. 245
Marc Nieper-Wißkirchen
(04 Dec 2023 10:48 UTC)
|
|
Re: 251 vs. 245
Daphne Preston-Kendal
(04 Dec 2023 11:03 UTC)
|
|
Re: 251 vs. 245
Lassi Kortela
(04 Dec 2023 11:24 UTC)
|
|
Re: 251 vs. 245
Sergei Egorov
(04 Dec 2023 11:33 UTC)
|
|
Re: 251 vs. 245
Marc Nieper-Wißkirchen
(04 Dec 2023 12:07 UTC)
|
|
Re: 251 vs. 245
Sergei Egorov
(04 Dec 2023 12:44 UTC)
|
|
Re: 251 vs. 245
Marc Nieper-Wißkirchen
(04 Dec 2023 12:52 UTC)
|
|
Re: Re : Re: 251 vs. 245
Amirouche
(04 Dec 2023 21:59 UTC)
|
On 4 Dec 2023, at 10:27, Amirouche <xxxxxx@hyper.dev> wrote:
> The wording, and specification of 251 is better, and makes explicit code reading practice.
>
> 251 forbid mutually recursive definition in <body> and that is easier that way.
251 does not forbid mutually recursive definitions; it merely makes them impossible when an expression (which, as previously mentioned, is not necessarily a transparent concept when reading) appears between two definitions.
So this is fine in 251:
(define (even-or-odd n)
(define (even? n) (or (= n 0) (odd? (- n 1))))
(define (odd? n) (even? (- n 1)))
(if (even? n) 'even 'odd))
But not this:
(define (even-or-odd n)
(define (even? n) (or (= n 0) (odd? (- n 1))))
(some-macro-that-expands-into-an-expression-or-a-mix-of-definitions-and-expressions)
(define (odd? n) (even? (- n 1)))
(if (even? n) 'even 'odd))
Either of these is fine in 245. Either is also fine in the R6RS top-level program. Either is also fine in an R7RS small library body. One of the purposes of 245 is to simplify Scheme by applying the same expansion order and scoping rules to all bodies. 251 could not do this even just for R7RS small.
The following also works in an R6RS top-level program body, but not in 251:
(define x (x-stx))
(some-expression)
(define-syntax x-stx
(syntax-rules ()
((_) some-expansion-for-x-stx)))
If the specification of 245 is not sufficiently complete, you could also look at the macrological fascicle’s adaptation of the R6RS expansion order, which (preliminarily, as noted) explains how R7RS extends the process to cover (among other new features) mixed definitions and expressions in any context:
<https://codeberg.org/scheme/r7rs/src/commit/f31ef57eff12a2606b5afcfd05273421a3fdf432/fascicles/syntax-fascicle.txt#L1090-L1195>
I didn’t include this in its entirety in 245 because, in fact, only one paragraph of the R6RS spec is affected by this specific change (as explained in the ‘R6RS-compatible semantics’ section). But I could add it at the last minute (less the additions for identifier property and syntax parameter definitions) if it would help 245 to have ‘better wording and specification’.
> It is different from top level libraries.
Ungrounded assertions do not an argument make. (How? Why?)
Daphne