Thanks for chiming in.

Am Do., 6. Okt. 2022 um 22:30 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Tue, Oct 4, 2022 at 3:16 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> 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.

Conciseness does not necessarily mean indecipherability. While I get
used to implicitly generated identifiers in R6RS record-type
definition, I don't think I can ever get used to (or even learn to
understand) such an APL expression. But this is, of course,
subjective.

>> > 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.

And there seemed to have been some misunderstanding about the why of
R6RS-style constructors.

>> > 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:

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, but, as I said, I am not against it either if
people want this.

> 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.

This would formally bring the second syntax on par with the first
syntax but would be much harder to parse as a human.

> 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.

This looks much better to me. (I think you forgot to add a "(" before
"foo", though.).

But what would it mean to give a protocol (name)? This should make the
constructor subform in the SRFI 9-syntax obsolete, but this would
change the overall syntax.

>> 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.

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?
Maybe.

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.

(There's another problem with the SRFI 99 syntax: it uses a
record-type descriptor whenever the R6RS syntax uses the record name.
Unless one is writing a (Scheme) interpreter in Scheme, record-type
descriptors and constructor-type descriptors should typically not
appear in code.)

So given the base record definition of a point as above, consider the
following example child record-type definition in R6RS style:

(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?