> On Oct 31, 2022, at 8:36 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Mo., 31. Okt. 2022 um 13:00 Uhr schrieb Marc Feeley
> <xxxxxx@iro.umontreal.ca>:
>
>> 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).
>
> A nongenerative clause without a UID has a defined meaning, sitting in
> between generative record types and non-generative ones with a UID:
> In the case of "global" library definitions, It means that a record
> type is generated per visit of a library, not one per instance of a
> library (as would be a generative record-type) and not one per big
> bang (as would be a non-generative record-type with a UID).
>
> I think this part of R6RS is okay; the actual problem is the library
> system of R6RS is not strict about the number of visits to a library,
> presumably so that, at that time, the module system of MzScheme was a
> faithful implementation.  (Notable, Racket does not allow a
> nongenerative clause without a UID.)  As we have agreed upon implicit
> phasing, we can remove this problematic part of R6RS (which makes it
> hard to write portable programs despite that this was a design goal of
> R6RS), by enforcing that libraries must only be expanded once per
> program run.  (This still needs UIDs in portable code for
> communication between different instances of the program if
> portability is required.)  In a sense, one can think of each visit
> having its own UID, and this being prepended to auto-generated UIDs of
> record-types.
>

As I say “most people will not fully grasp the meaning of a UID-less nongenerative record type definition”.  But thanks for pointing out that it is not even consistent between implementations and Racket has dropped UID-less nongenerative records.

When you say “we can remove this problematic part of R6RS” you mean remove UID-less nongenerative records?  You have my vote for that.

> If we can't agree to change the default from generative to
> non-generative, what we can do instead is to allow the non-generative
> clause to be of the form "(nongenerative #f)" and to advise
> implementations to issue a warning when it sees a record type without
> a non-generative clause of either form.

Double negatives are not great.  Moreover (nongenerative #f) is too easy to confuse with (nongenerative) because #f often means “not supplied” in many APIs.

By the way I wasn’t saying I’m against making the nongenerative case the “default”.  But what does “default” mean here if a UID needs to be supplied with the clause? “Default” only makes sense if the UID-less variant is supported, and I think that would be a blunder.  Isn’t the real issue one of educating programmers rather than syntax?

>
> Marc
>

Marc