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);

For those of you who enjoy reading the tax code, I've uploaded into RC_1_33_0 my latest attempt resolve this issue. Its in boost/libs/seiralization/doc/ I believe this will be found to be at least a great improvement. I sure hope so. I've strived to full the the requirements for formal documentation as I understand them. BTW - is there any formal specification of what constitutes formal documentation? The discussion sounded like there was but a cursory web search didn't turn up anything. Also, careful examination of different documentation suggests, that although they have lots of similarities - there are enough differences to make me believe that there really is no universally accepted definition for this. Robert Ramey