On Thu, Oct 6, 2022 at 5:11 PM Marc Nieper-Wißkirchen <[email protected]>
wrote:
> And there seemed to have been some misunderstanding about the why of
> R6RS-style constructors.
>
That's true: the "why" of protocols is not well explained either in R6RS or
in TSPLv4.
>
> I am not convinced that is necessary to provide the second form of
> `define-record-type` with all bells and whistles as long as R7RS-small
> compatibility is there
>
It is of course not *necessary*, but it accommodates R7RS-small users who
wish to make use of one of the R6RS features without learning the entirely
new syntax.
This would formally bring the second syntax on par with the first
> syntax but would be much harder to parse as a human.
>
Agreed.
> This looks much better to me. (I think you forgot to add a "(" before
> "foo", though.).
>
Yes. So let's adopt the p-list-style extension to R7RS:
(define-record-type (foo parent bar) ...)
>
> But what would it mean to give a protocol (name)?
>
All right, we can do without that (see below). So `parent`, `sealed`,
`opaque`, and `nongenerative` would be allowed in any order.
>
> I am not sure how much this still looks like SRFI 9-syntax when there
> are a lot of entries next to the record name. Would it really be
> better (for SRFI 9-users) than the first syntax given in this SRFI?
>
>
Yes, I think so:
(define-record-type foo
(make-foo bar baz)
foo?
(bar foo-bar-ref)
(baz foo-baz-ref foo-baz-set!))
(define-record-type (extfoo parent foo)
(make-extfoo quux)
extfoo?
(quux foo-quux-ref))
If this extension to R7RS-small syntax is accepted, the question remaining
is whether the purely syntactic features of SRFI-99 should also be
provided. I think the answer is no, per SRFI 131. The reason is not, as
in SRFI 131, in order to allow a syntax-rules implementation, but simply
because SRFI 9 / R7RS-small users are already accustomed to providing
explicit names.
> In any case, however, the problem of interpreting field names in SRFI
> 9-style constructors in child record-type definitions remains. They
> cannot refer to parent fields (as SRFI 99 says) for R7RS-small
> compatibility, so the only solution seems to be that the names
> correspond solely to child fields and that the parent constructor's
> formal arguments are implicitly added at the beginning.
>
The bulk of all constructors include all the arguments anyway; the typical
case is to hide the complete constructor in a library and export an
ordinary function that does whatever's necessary to set up the fields
correctly.
> (define-record-type colored-point
> (nongenerative) (opaque #t)
> (parent point)
> (fields color)
> (protocol
> (lambda (n)
> (lambda (x y c)
> (assert (memq c '(red green blue))
> ((n x y) c)))))
>
> What would a translation of this into SRFI 9-style look like?
>
It wouldn't; see above.
