Re: [boost] [serialization docs] Ping?

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-22 23:10:40

Very interesting.

First I'm surprised that anyone else was even looking at that thread after 
all this time.

Its clear that there is a strong parallel here - maybe even a one-to-one 
correspondence.

I've concluded that the concept of Semantic really isn't formal. Its a 
narrative description of
what someone expects an expression to do.  This will often have some 
unavoidable
ambiguity. That doesn't make it useless its just that I don't think a 
semantic description
can every be definitive.  So I think I can just add a plausible narrative 
description that
I think will satisfy everyone.

In a year this has never come up.  I suspect that this is because people who 
read the
documentation already have an intuitive idea about what the expressions mean 
from
reading the tutorial.   Of course, there's no harm in trying to concisely 
explain them.
But I think its naive think that they are going to be definitiive or 
all-encompassing.

The C++ compiler can enforce correct usage of the concepts but it can't do 
the
same for the semantics unless they are written so narrowly so as to be of 
little value.
We don't want to stop someone from using a class modeling the Saving Archive 
Concept
as a debug log even if our semantic narative says the valid expressions are 
meant
to fullfill a different function.

Once one recognises this inherent limitation, there's not much justification
to try specify something like equivalence in anything more than some sort
of appeal to common sense and intuition.  Constant class members are
a good example.  In one application or class they might be considered
as part of some sort of equivalence relation.  In a different context they
might not.  I don't see how you eliminate all the ambiguity from the 
definition
without excluding useful applications of the library.  Sooner or later
we get to the point where we just have to assume we have shared
understanding on what words mean.  The question is where does one stop.
This is a subjective determination.

Anyway ,your informaton was very informative in that its clear that
someone else has been here before.

Robert Ramey

Kim Barrett wrote:
> This is in regard to the discussion of the "equivalence" of a
> serialized object and the deserialized counterpart. It also touches on
> the Serializable concept and some recent discussion of how classes
> without default constructors can be handled, and a few other things
> besides. (Sorry about the entanglement, but I'm not sure how to
> separate some of these issues.) (Note that I also haven't read *all*
> of the mail on this subject yet.)
>
> The Common Lisp committee (X3J13) needed to deal with essentially the
> same problem.
>
> The term that was eventually adopted was "similar" or "similar as
> constants" where further disambiguation was needed. I think that would
> be a good term for the serialization library to adopt, as it avoids an
> implications related to operator== and the ambiguity around the word
> "equivalent".

My inclination is to use the word "equivalent" along with a qualifying 
sentence
that it is of necesity ambiguous.

> A protocol was designed to permit instances of arbitrary user-defined
> classes to be saved and loaded. (Sound familiar? Note that support for
> different data formats for that saving and restoring was only
> addressed to the extent that different CL implementations likely had
> different compiled file formats and were not required to be
> compatible; something like the idea of binary / text / XML / whatever
> archives was not addressed, and never even came up, so far as I can
> recall. A missed opportunity there.)

>   "The \term{file compiler} must cooperate with the \term{loader} in
>   order to assure that in each case where an \term{externalizable
>   object} is processed as a \term{literal object}, the \term{loader}
>   will construct a \term{similar} \term{object}."
>
> Substituting serialization library terminology into that quote:
>
>   The saving archive must cooperate with the loading archive in order
>   to assure that in each case where a serializable object is saved,
>   the loading archive will construct a similar object.
>
> I think it should be reasonably straightforward to massage this into a
> statement about whether a saving archive and a loading archive are
> compatible.

I can buy this.  I think language similar to that - with that level of 
informality -
will work well here.

> The CL protocol for loading involved a two step process. First, a
> constructor is called with some arguments. Then, optionally, an
> initialization form is called called, which contains references to the
> constructed object in order to perform additional modifications to it.
>
> I *think* this protocol is strictly more powerful than that presently
> specified by the serialization library. An example of a class that I
> don't know how to "serialize" is a "symbol" lazily constructed on
> named lookup; the save/load_construct_data mechanism is inadequate for
> this.

As far as I can till this is identical to what the serialization library 
does
when it loads a pointer.  At least to the extent that C++ and CLOS
are similar.

(There are also object graphs containing reference cycles that
> might not be serializable but are CL externalizable, because the
> reference cycle can be broken by using the two stage protocol. I
> haven't looked to see whether the serialization library installs an
> object in the "pointer table" (whatever it is called) at allocation
> time or only after it has been initialized via deserialization.)

the serialzation library handles cycles of pointers with no special
efforts required.  I suspect that, allowing for differences in the
languages themselves, the systems are functionally identical.

> Attempting to translate the CL protocol into C++ terminology, I
> think it would consist of first calling a static factory function
> associated with the type,

This is part of the implementation as pointer_iserializer<T, 
Archive>::load_object_ptr

> passing it the archive as an argument, and
> then calling a member function on the object, again passing the
> archive as an argument.

which is
template<class Archive>
serialize(Archive &ar, T & t, const int version);