Hi, thanks for your comments.

At Wed, 16 Jun 2004 08:35:28 +0200, Felix Winkelmann wrote:
>
> - all the "write-..." procedures in the document are missing the "[port]"
>    argument.
> - The section "Library Procedures" says something about bullets
>    "(*)", but there are no bullets.
...
> - the links to the ref. implementation and test-suite are broken.

This was part of a bug in the converter from text to html.  I've
attached a more recent version with the [port]s included and have
changed the wording about bullets.  The reference implementation is at
the same URL substituting .scm for .html.

The section on string ports has also been removed.  Forget it please
:)

> - "General Reading":
>
>    "Schemes are not required to support the full numeric tower, and
> in particular if they do not support bignums they are unlikely to be
> able to provide the full range of 32-bit values."
>
>    That should mean SIZE is limited to whatever the implementation
>    can handle, right?

Yes.

>    "32-bit" means "machine-word size", I assume.

Yes, I'll change that.

> - Since there are Schemes that provide only fixnums and flonums, I would make
>    [read|write]-[binary|network]-[s|u]int64 optional, as does SRFI-4.

Sounds good, I'll add something similar.  Likewise the *-ieee-*
procedures will be optional if the Scheme does not support inexact
reals.

> - Actually, I think [read|write]-ber-integer should be thrown out,
> they belong into a different SRFI.

Part of the reason for including those is for use in my Perl
pack/unpack implementation, so I'm admittedly biased.

Pros: as I see it are that most Schemes provide bignum support so when
reading and writing binary numbers you may not want to restrict
yourself to a specific size.  It is also a fairly simple and compact
encoding, but for speed and portability better offered as part of a
standard library.

Cons: it's not a complete solution, in that it doesn't handle negative
numbers or rationals, though these can be trivially defined in terms
of it.  It is also originally from a much more complex standard.

As for moving it to a different SRFI, a likely future SRFI may be
binary serialization.  However, that would probably use tagging
information, and several different serialization techniques may or may
not build on the BER representation, which would suggest it be part of
a more basic library.

What do other people think?

--
Alex