> On Oct 31, 2022, at 5:11 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am So., 30. Okt. 2022 um 23:20 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>>
>>
>>
>> On Sun, Oct 30, 2022 at 12:57 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>
>>>
>>> Global record-type definitions are effectively non-generative.
>>
>>
>> Quite so.  So even if the default kind of record-type is generative, the global ones can be treated as if they are non-generative, which means there is no additional overhead for most record types.
>
> To recognize this, a sufficiently smart compiler is needed, of course,
> and it depends that no relevant extensions past R[67]RS are present.
> As soon as the implementation allows to load a library several times,
> a generative record-type definition cannot be compiled as a
> non-generative one.

I totally agree.  The meaning of “global” is not what it used to be in the days when “a program’s execution” was strictly delimited by its launch and termination.  It is becoming more common to have objects outlive the launch/termination of the program that contains the type definition:

1) Saving the state of the program in a “heap image” for restoring it in a future execution of the program.

2) Serializing an object to be saved in an object store or some file (many use-cases for this including a Scheme compiler saving the type descriptors of a library being compiled into its final compiled form… these type descriptors must be of the same “type descriptor” type when a linker reads these libraries to generate the final executable program).

3) For computing systems composed of multiple OS processes that communicate (a distributed system) there’s a need for (at least) two separate and concurrent executions and serializing/deserializing objects from one to the other system.  Moreover it must be possible to send an object X from A to B, and then again from B to A and get an object with the same type.

So it would be limiting to assume that a global generative record type definition is the same thing as a nongenerative record type definition.  It only works when the lifetime of the objects is contained in a program’s execution.

However I’m not arguing that nongenerative record definitions should be the default even though in the Gambit codebase most if not all of the record type definitions are nongenerative.  Due to the presence of a UID the nongenerative record definitions are a bit more verbose and visually inelegant than generative ones.  Note that I think R6RS has a design error in allowing nongenerative record definitions without a UID (it just slightly shifts the meaning of type instantiation and will not work in the above use cases and most people will not fully grasp the meaning of a UID-less nongenerative record type definition).

Marc