Perpetuity of non-generative record type definitions Marc Nieper-Wißkirchen (02 Nov 2022 07:10 UTC)
Re: Perpetuity of non-generative record type definitions Marc Feeley (02 Nov 2022 10:18 UTC)
Re: Perpetuity of non-generative record type definitions Daphne Preston-Kendal (02 Nov 2022 10:28 UTC)
Re: Perpetuity of non-generative record type definitions Marc Nieper-Wißkirchen (02 Nov 2022 10:41 UTC)
Re: Perpetuity of non-generative record type definitions Marc Nieper-Wißkirchen (02 Nov 2022 10:49 UTC)
Re: Perpetuity of non-generative record type definitions Marc Nieper-Wißkirchen (02 Nov 2022 10:37 UTC)
Re: Perpetuity of non-generative record type definitions Marc Feeley (02 Nov 2022 12:28 UTC)
Re: Perpetuity of non-generative record type definitions Marc Nieper-Wißkirchen (02 Nov 2022 12:50 UTC)
Re: Perpetuity of non-generative record type definitions Marc Nieper-Wißkirchen (02 Nov 2022 12:55 UTC)

Re: Perpetuity of non-generative record type definitions Marc Feeley 02 Nov 2022 10:18 UTC

> On Nov 2, 2022, at 3:10 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> I want to point out that non-generative record-type definitions must
> not be garbage collected whether there are any references to the
> corresponding record-type descriptor (or records of this type) or not.
>
> The reason is that `make-record-type-descriptor' and similarly
> `make-record-descriptor' and `define-record-type' must detect the
> redefinition of a non-generative record type with incompatible shape.
>
> This has the consequence that in a long-running Scheme process (whose
> extent can exceed any Unix process and that can even be distributed),
> if a non-generative record type definition is modified in a source
> file, the Scheme system will complain unless the corresponding UID is
> changed as well.  While this appears tedious, it is a good thing
> because it prevents silent errors when different parts of the process
> try to communicate through incompatible record types.

I think this (the “must” detect the redefinition) would be too big of a burden on the implementation.  It is not even clear what scope the registry must have (I would think it needs to be at the same level as a library registry because some other programmer may be redefinining the record type with no prior compilation of the original record type).

In any case, there is a simpler approach, namely to create a hash of the relevant parts of the record definition and to combine this hash with the UID.  That way, if the number of fields, the name of the fields, the UID, etc change then the type will effectively be a different type.

Marc