Am So., 30. Okt. 2022 um 17:37 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Oct 30, 2022 at 5:09 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> 95% or more of the record-type definitions in practice are supposed to
>> be nongenerative.
>
>
> What is the evidence for this claim?  As far as I know, almost all record-type definitions are global, which means it makes no difference whether they are generative or non-generative.

Global record-type definitions are effectively non-generative.

Local record-type definitions are helpful if one wants to use lexical
scoping.  If the type to be defined is only used locally in a
procedure (which includes a macro transformer, for example), this can
be good coding practice to prevent pollution of the (module-)global
namespace.  If these local record-type definitions were generative,
the "good coding practice" would lead to inefficient code.

The only use case of generative record-type definitions is the
creation of new types on the fly, e.g. to implement SRFI 137 (but note
that SRFI 137 has other implementation strategies as well).  But
define-record-type has severe limitations in this (minor) use case
because all generated types must be of the same shape.  This is one of
the few cases where the procedural interface can make more sense.

Non-generative record-type definitions are probably what most people
expect anyway (I know at least of Daphne, who thought that R7RS
definitions were non-generative [*]). Other definitions also have
non-generative behavior; in

(define foo
  (lambda (x)
    (define-syntax bar (lambda (stx) ... ))
    (bar x)))

the macro transformer (lambda (stx) ...) is only evaluated once and
not per invocation (foo X).

I am not alone in my assessment; see section 7.13 in the Chez Scheme
User's Guide ([1]).  Kent Dybvig has certainly much more experience
with R6RS record-types than I do.

Marc

PS I didn't prove the 95% exactly; it should stand for a number
sufficiently near 1.

--

[*] For R7RS Small, generativity was the right choice, because it is
more expressive (but prevents the use of lexical scoping to write
clearer code) given that there is no flag to switch between
generativity and non-generativity.
[1] https://cisco.github.io/ChezScheme/csug9.5/objects.html#./objects:h13