On Tue, Oct 4, 2022 at 3:16 PM Marc Nieper-Wißkirchen <[email protected]>
wrote:
> 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))`.
Having had experience with concise languages like APL and K, I don't think
that concision is a particular advantage compared to clarity. Overall, I
prefer (lambda (list) (/ (fold + 0 list) (length list))) to {(+⌿⍵)÷≢⍵}.
But it's mostly a matter of taste, and I'm fine with having both forms
available, given that they have both been standardized.
> However, I still maintain that we should abandon or deprecate the idea of
> the record constructor descriptor,
I agree that this is OT for this SRFI.
> > 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.
>
I firmly agree with this. There are a number of possible approaches:
1) Allow an alternative to the record name (an identifier), namely a list
of the form (record-name parent-record-name-or-#f protocol-name-or-#f
sealed-boolean opaque-boolean uid-or-boolean), where the last value is a
uid, a #t if the record is non-generative and the uid is chosen by the
implementation, or #f if the record is generative. The order is that given
in the R6RS report, and trailing #f's can be omitted from the list.
2) Allow a plist to which the record name is consed:
(define-record-type foo parent bar protocol baz) ...). Alternatively, an
alist or 2-element alist.
I have been unsuccessful so far, partly because the SRFI 9 syntax,
> which the small language adopted, is very inflexible and hard to
> extend.
As shown above, it can be extended.
