Am Di., 4. Okt. 2022 um 20:22 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> Glad to see this has made it to SRFI stage.
>
> As I said elsewhere while this was still in pre-SRFI state, although I strongly dislike the magic generation of identifiers and thus generally dislike R6RS define-record-type syntax, I would vote for this (with the changes below, especially the latter ones) as a resolution to the conflict between the R6RS and R7RS camps on the record type issue.

The "magic generation of identifiers" has both advantages and
disadvantages.  The obvious disadvantage is that it makes it harder to
use grep (at least as long as you are not accustomed to searching for
record-type definitions). On the other hand, a significant advantage
is that record-type definitions can be as concise as in
`(define-record-type point (fields x y))`.  As one can always write
out all introduced identifiers - as in `(define-record-type (point
make-point point?) (fields (immutable x point-x) (immutable y
point-y))` -, I think the current state of affairs is fine for
everyone.

> However, I still maintain that we should abandon or deprecate the idea of the record constructor descriptor, i.e. the (default) record constructor descriptor should be rolled into the record type descriptor together and bound to the name given by the ⟨name spec⟩/⟨name⟩. The whole idea of the record constructor descriptor is over-engineering – if I want a custom constructor with default values or whatever, I write a simple wrapper procedure.

If a constructor in the sense of R6RS were no more than a simple
wrapper procedure, I would see your point, but it isn't.  The proper
constructor procedure enters in inheritance when records of a child
type are constructed.  You don't get this abstraction with wrapper
procedures.

In any case, if one doesn't need this abstraction in one's code, one
doesn't have to use this feature, meaning the protocol clause in
record types. (On the other hand, a record constructor descriptor
won't appear in most code bases (even if they employ custom
constructors) because the use of the procedural interface does not
make sense for the vast majority of applications.)

> This also means it would be possible to define a subtype of a record type in the SRFI 99 style, which I believe is essential. If we’re going to have opaque, sealed, and nongenerative records (which I don’t like, but can live with again for the sake of peace with the R6RS camp, if it will bring it), the R7RS style syntax should also be extended with a way to create those. If we’re going to support both styles, neither should be a second class citizen in terms of feature set.

As for opaque, sealed, and non-generative records, I gave reasons in
the SRFI why they can be essential in applications. Again, if you
think you don't need these attributes, you don't have to use them.

As it is well-known, the problem with the SRFI 99 syntax is that it is
incompatible with the small language's interpretation of record field
names as (hygienic) identifiers (which is a sensible interpretation
for a language like R7RS-small that only has syntax-rules). I am
willing to add syntax to add features to the second syntax of
`define-record-type` described in this SRFI if you can come up with
straight-forward syntax, that does not clash with the existing syntax,
and that can work with record field names as (hygienic) identifiers.

I have been unsuccessful so far, partly because the SRFI 9 syntax,
which the small language adopted, is very inflexible and hard to
extend.  It does its job well for a record-type facility without
inheritance as in SRFI 9 and R7RS-small, but doesn't offer a clear way
to add extensions.

Marc

PS Some of the discussion above is slightly off-topic for this SRFI,
whose purpose is to provide a syntax that encompasses both the R6RS
and the R7RS record-type facility. Removing bits of one or the other
facility would thus be against the spirit or idea of this SRFI.