Am Di., 4. Okt. 2022 um 20:22 Uhr schrieb Daphne Preston-Kendal <d...@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.
