Am Do., 2. Feb. 2023 um 04:04 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Feb 1, 2023 at 3:21 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> SRFI 237 is supposed to be a conservative refinement of the R6RS
>> record facility.
>
>
> In that case it would be helpful to say so, and to only document the non-RnRS features, since (rnrs records) will already be part of R7RS-large.  It's also unclear why you have any library other than (srfi 237 syntax); if you want procedural records, you can simply import (rnrs record procedural).  I was also going to add that the warnings should be changed to errors, but I agree that if you want full backward compatibility that doesn't make sense.

On an R6RS system implementing SRFI 237, (srfi :237 records
procedural) will, in general, be different to (rnrs records procedural
(6)).  The reason is that the domains of the procedures in (rnrs
records procedural (6)) must not be silently extended.  (Moreover,
(srfi :237 records procedural) also export
record-constructor-descriptor?, which is not part of the R6RS
library.)

On an R7RS system implementing SRFI 237, it makes sense to offer, say,
(srfi 237 inspection) independently of (rnrs records inspection).

Thus I think there are good reasons to keep the libraries packaged as
they are in SRFI 237, in particular, as these library names are cheap
thanks to namespacing.

These considerations are for R6RS and R7RS-small systems.

Now, for R7RS-large, the idea is that

(rnrs records syntactic (7)), (rnrs records procedural (7)), (rnrs
records inspection (7))

will be equivalent to the respective (srfi :237 records ...)
libraries.  Moreover, (scheme base) exports the define-record-type of
SRFI 240, and, for consistency of naming, a library (scheme record) is
added that exports all the identifiers defined in SRFI 237 and SRFI
240.

R6RS programs (not relying on "mustard") will then work unchanged
under the large language as will, of course, any program written for
R7RS-small.

Marc