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:50 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:41 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:38 UTC)
|
Re: Reviewing named and optional parameters
Peter Bex
(08 Jun 2021 05:18 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:01 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:30 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:26 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:19 UTC)
|
Re: Reviewing named and optional parameters
John Cowan
(12 Jun 2021 22:09 UTC)
|
Re: Reviewing named and optional parameters
Daphne Preston-Kendal
(21 Jun 2021 07:22 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:40 UTC)
|
Re: Reviewing named and optional parameters
Marc Nieper-Wißkirchen
(30 Jul 2021 21:48 UTC)
|
Re: Reviewing named and optional parameters
John Cowan
(30 Jul 2021 21:50 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:46 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)
|
> 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