Am Do., 2. Feb. 2023 um 04:04 Uhr schrieb John Cowan <[email protected]>: > > > > On Wed, Feb 1, 2023 at 3:21 PM Marc Nieper-Wißkirchen <[email protected]> > 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
