Re: binary interface

[Dirk Herrmann]

On Sun, 25 Feb 2001, Keisuke Nishida wrote:

> At Fri, 23 Feb 2001 11:19:01 +0100 (MET),
> Dirk Herrmann wrote:
> > 
> > Actually, no.  It shows a solution for the problem that we have already
> > solved, namely how to store/restore a _single_ structure.  However, since
> > we know how to correctly restore a single struture, a workaround for the
> > moment can be to put all objects that are to be binary-written into an
> > array, and then write this array.  It may be that this is the only
> > solution for the problem that makes sense - look at the following example:
> 
> In this case, all objects are actually written when you close the port,
> right?  But if you want to copy objects using a network port, that is
> probably not what you want. (Or maybe we shouldn't use a network port.)

No, sorry for being unclear.  I think, binary-write should write its
object at once with all dependant objects.  In other words, binary-write
guarantees to write the object and all dependant objects in their state at
the moment that binary-write was called (let's ignore threading here...).
No information about object sharing is preserved between two consecutive
calls to binary-write to the same port. Thus, it is a _user_level_ trick
to put multiple objects into a vector and then write that vector as a
single object.

> >   (define foo (cons 'a 'b))
> >   (binary-write foo <some-port>)
> >   (set-car! foo 'c)
> >   (binary-write foo <some-port>)
> 
> Probably situations like this shouldn't be guaranteed.  Otherwise,
> a restricted interface like (dump OBJ FILENAME) might be better.

With the approach I have sketched above, writing 'foo' twice with two
separate calls to binary-write will write out the _whole_ set of objects
that are reachable from foo twice.  Otherwise I see no chance to define a
consistent semantics for how eq? objects should be preserved between calls
to binary-write.

BTW:  Now that a mechanism for writing objects binary exists, are there
yet any benchmark results telling us about the benefits with respect to
size and loading time?  If these are not significant, we should re-think
the idea of adding support for binary-writing, and instead take a look at
SRFI-10 as a means to store and read arbitrary data, potentially combined
with the (PROGN (SETF A (1 #1=(A B C))) (SETF B (2 #1#))) style for
denoting circular structures.  After all, adding the possibility to binary
read and write objects is a big change, and its usefulness still needs to
be proven.

Best regards,
Dirk Herrmann