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 12:27 UTC

> On Nov 2, 2022, at 6:36 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> In any case, when we want to support the reading and writing of
> records, some solutions (and probably the simplest ) require that a
> record-type registry must be maintained anyway:
>
>> (define-record-type foo (nongenerative ...) ...)
>> (gc)
>> (read)
> <external representation of record type foo>

Please don’t force implementations to use a (centralized) registry.  Decentralization is necessary for code mobility.

To solve write/read invariance of records the external representation has to contain as much relevant information as the record type declaration.  Gambit does this.  In a distributed setting node A can send a record to node B, and then node B sends it back to A, and the same type is gotten on A.  Moreover, B does not even have to be running code that contains that record type definition.

Marc