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 Nieper-Wißkirchen 02 Nov 2022 12:49 UTC

Am Mi., 2. Nov. 2022 um 13:28 Uhr schrieb Marc Feeley <xxxxxx@iro.umontreal.ca>:
>
>
> > 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.

No centralized repository is needed; at some point, one just has to
transfer the definition of a record type from node A to node B at some
point.  This can happen by serializing a record-type definition and
sending it over the wire, or one can use the Gambit approach by
effectively sending the record-type definition each time along with a
record.