Sorry, I did not think this through completely. Serialization of cstructs, as
it is currently implemented, loses all “sub-structure” for non-pointer content,
correct?
But wouldn’t because of this lost sub-structure your alternative compatibility
protocol also fail when it comes to hierarchically embedded structs where deep
down in the hierarchy a new version of a struct should be used?
(define-serializable-cstruct _pond ([depth _float]))
(define-serializable-cstruct _forrest ([a_pond _pond]))
and then a new version:
(define-serializable-cstruct _old-pond ([depth _float]))
(define-serializable-cstruct _pond ([num-fish _int]
[depth _float])
(define-serializable-cstruct _forrest ([a_pond _pond]))
So, the version of _forrest does not change and, hence, there is no way to
deserialize the correct, new version of the _pond.
I think this could only be resolved by changing the serialization so that it
keeps all relevant information also for non-pointer content.
Berthold
> On 06 Jun 2016, at 19:22, Matthew Flatt <mfl...@cs.utah.edu> wrote:
>
> Yes, but I think a different protocol will be needed than for
> `serializable-struct`.
>
> With
>
> (serializable-struct pond (depth))
>
> it's clear that the deserializer receives a single value for the single
> field (or, more generally, N values for N fields). So, it's clear how
> to make a compatibility deserialization function:
>
> (serializable-struct/versions pond 1 (num-fish depth)
> ([0 (lambda (d) (pond 0 d))
> (lambda () ....)]))
>
> With
>
> (define-serializable-cstruct _pond ([depth _float]))
>
> the deserializer internally deals with a byte-string representation of
> non-pointer content plus a structured representation of pointer
> content. We probably don't want to expose those details, and you don't
> want to deal with them.
>
> An alternative it to make the compatibility protocol work in terms of a
> separate cstruct declaration:
>
> (define-serializable-cstruct _old-pond ([depth _float]))
>
> (define-serializable-cstruct _pond ([num-fish _int]
> [depth _float])
> #:version 1
> #:other-versions ([0 deserialize-chain:cstruct:old-pond
> (lambda (op)
> (make-pond 0 (old-pond-depth op)))
> (lambda () ....)]))
>
> That is, compatibility deserialization is based on a reference to
> deserialization information for a cstruct that has the same shape as
> the old version, plus converters from instances of the old shape to the
> new cstruct.
>
> Does that interface seem ok?
>
>
> At Sun, 5 Jun 2016 22:04:23 +0200, Berthold Bäuml wrote:
>> Would it be possible to add for the serializable cstruct
>> (define-serializable-cstruct) versioning like in
>> define-serializable-struct/versions?
>>
>> Berthold
>>
>> --
>> -----------------------------------------------------------------------
>> Berthold Bäuml -- Head of Autonomous Learning Robots Lab
>> DLR, Robotics and Mechatronics Center (RMC)
>> Münchner Str. 20, D-82234 Wessling
>> Phone +49 8153 282489
>> http://www.robotic.de/Berthold.Baeuml
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
--
-----------------------------------------------------------------------
Berthold Bäuml -- Head of Autonomous Learning Robots Lab
DLR, Robotics and Mechatronics Center (RMC)
Münchner Str. 20, D-82234 Wessling
Phone +49 8153 282489
http://www.robotic.de/Berthold.Baeuml
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
