Re: Guile Binary Format 0.1

[Dirk Herrmann]

On Mon, 5 Feb 2001, Keisuke Nishida wrote:

> I have implemented this version.  Now objects are stored using a stack.
> When scm_dump_object is called and the object has not been stored yet,
> it is pushed into a stack and the rest of tasks are automatically
> scheduled.  So a smob writer don't need to think about it.

That is much more comfortable.

> An undump function looks like this:
> 
>   SCM
>   foo_undump (SCM dstate)
>   {
>     struct foo *p = scm_must_malloc (sizeof (struct foo), "foo_undump");
>     p->x = scm_undump_word (dstate);
>     p->y = scm_undump_word (dstate);
>     scm_undump_object (&p->bar, dstate);
>     scm_undump_object (&p->baz, dstate);
>     SCM_RETURN_NEWSMOB (scm_tc16_foo, p);
>   }
> 
> It's not symmetry, but probably this is easier to use.  [...]

Well, I liked your symmetric version better.  Otherwise, the interface has
become quite elegant!

> [...]  If you want
> to dump/undump a cell object, you should write it as follows:
> 
>   SCM
>   foo_dump (SCM obj, SCM dstate)
>   {
>     scm_dump_cell_object (SCM_CELL_OBJECT_1 (obj), dstate);
>   }
> 
>   SCM
>   foo_updump (SCM dstate)
>   {
>     SCM smob;
>     SCM_NEWSMOB (scm_tc16_foo, smob, 0);
>     scm_undump_cell_object (smob, 1, dstate);
>     return smob;
>   }

I don't understand this.  Why do you treat cell objects differently from
other objects?

> There are some potential places of improvement, though.  Since
> objects are dumped from the beginning, lots of reference linking
> can be delayed during undump.  For example, a list (foo bar) is
> stored as follows:
> 
>   [\?GBF ][-0.1][   4]
>   [cons  ][  #1][  #2]
>   [symbol][foo ]
>   [cons  ][  #3][  ()]
>   [symbol][bar ]
> 
> When the first cons is undumped, object #1 and #2 are not yet
> created, so linking are delayed and scheduled using malloc.
> This may produce a number of of malloc calls.  [...]

What do you need malloc calls for?  I would say, if the first cons object
is undumped, you create exactly the cons cell that you want to
create.  However, you fill it with #f instead of with the real
objects.  No malloc needed, or am I missing something?

> I haven't fixed the smob tc problem yet.  Only file ports
> with mmap are supported.  Only one object can be read.
> No documentation yet.  I'll add them some time later.

The point about the smob tc (and, actually any tc) problem is, that you
probably wouldn't want to store a full type description with any single
object:  If you were to store a couple of integers, it would be very space
consuming to write out the string "integer" ahead of every single
number.  So, one could alternatively allocate typecodes dynamically during
writing/reading, comparable to the way that object reference numbers are
generated dynamically.

> I appreciate any comments.

It looks very promising.  Thanks for working on it!

Best regards,
Dirk Herrmann