Reviewing named and optional parameters Daphne Preston-Kendal 07 Jun 2021 15:45 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 07 Jun 2021 16:07 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 08:49 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 09:13 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 09:42 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 10:24 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 10:32 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 12:16 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 12:40 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 13:10 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 15:56 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 18:15 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 10:27 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 14 Oct 2021 10:42 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 17:22 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 17:37 UTC
Re: Reviewing named and optional parameters Peter Bex 08 Jun 2021 05:17 UTC
Re: Reviewing named and optional parameters Per Bothner 08 Jun 2021 05:38 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 09:00 UTC
Re: Reviewing named and optional parameters Per Bothner 10 Jun 2021 17:23 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 07:23 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 08:55 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 14:29 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 14:44 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 17:03 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 17:33 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 17:37 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 17:40 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 19:01 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 19:25 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 10 Jun 2021 10:17 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 10 Jun 2021 11:18 UTC
Re: Reviewing named and optional parameters John Cowan 12 Jun 2021 22:08 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 07:21 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 10:37 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 29 Jul 2021 09:42 UTC
Re: Reviewing named and optional parameters John Cowan 29 Jul 2021 23:34 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 30 Jul 2021 07:03 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 30 Jul 2021 07:31 UTC
Re: Reviewing named and optional parameters John Cowan 30 Jul 2021 21:39 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 30 Jul 2021 21:47 UTC
Re: Reviewing named and optional parameters John Cowan 30 Jul 2021 21:49 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 30 Jul 2021 21:59 UTC
Re: Reviewing named and optional parameters John Cowan 30 Jul 2021 21:32 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 31 Jul 2021 10:02 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 31 Jul 2021 10:29 UTC
Re: Reviewing named and optional parameters John Cowan 31 Jul 2021 17:33 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 31 Jul 2021 17:45 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 31 Jul 2021 18:04 UTC
Re: Reviewing named and optional parameters John Cowan 31 Jul 2021 19:52 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 02 Dec 2021 17:57 UTC
Re: Reviewing named and optional parameters Jeronimo Pellegrini 03 Dec 2021 03:32 UTC

Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 18:15 UTC

> On Jun 9, 2021, at 11:56 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> How is the serialization of record types (say SRFI 9/R7RS or R6RS record types) handled?

Record types (which are defined with `define-type` in Gambit) are essentially vectors with the first field that is the type descriptor, which is also a record.  The type descriptor of type descriptors has itself as a type descriptor.  This circularity is not a problem because the serializer can handle cycles and shared parts of the structure.

A simple use of `define-type` creates a generative record type, so two identical record type definitions are in fact defining different types.  This is implemented by a field of record type descriptors which is the “id” of the type descriptor.  Each evaluation of a `define-type` generates a new “id” (an uninterned symbol), similarly to gensym.

So when such a record is serialized and then deserialized the type descriptor’s id will be a different uninterned symbol and the deserialized record will be of a different type:

> (define-type point x y)
> (define p1 (make-point 11 22))
> (define p2 (make-point 11 22))
> (equal? p1 p2)
#t
> (define p3 (u8vector->object (object->u8vector p1)))
> (equal? p1 p3)
#f
> (point? p3)
#f

To allow records to be serialized/deserialized while maintaining their type identity the `define-type` form takes an optional id: keyword argument to force the use of a specific (interned) symbol as the id.  For example:

> (define-type point x y id: some-unique-identifier)
> (define p1 (make-point 11 22))
> (define p2 (make-point 11 22))
> (equal? p1 p2)
#t
> (define p3 (u8vector->object (object->u8vector p1)))
> (equal? p1 p3)
#t
> (point? p3)
#t

In practice the id is chosen by the programmer to be universally unique by calling the uuidgen program whenever a new record type is defined or its definition has changed.  So most record type definitions in the Gambit runtime system look like this:

(define-type point x y id: B12D8099-40D3-45E4-9972-793141FDC38A)

and consequently it is possible to send such records to other nodes in a distributed system without causing a change in their type.

Marc