At Fri, 17 Sep 2004 23:53:33 +0200, Hans Oesterholt-Dijkema wrote:
>
> I've some questions about the naming of primitives provided in SRFI-56.
>
> 1. Why, is the word 'binary' used in the function definitions.
>    Is it not clear from the way the types are provided, that these
>    must be binary constructs?
>
>     read-uint32 is shorter and I think evenly clear as read-binary-uint32
>
>    It would spare a lot of typing work when programming.

I had considered the former, but was trying to be as clear as
possible.  Brevity is not a strong argument, but in retrospect I'm not
sure read-binary-uint32 is any more clear than read-uint32.

> 2. Why are the network encodings provided as separate functions?
>    Why not add 'network to 'big-endian and 'little-endian?
>    It's just an other way to encode your information.

'network is equivalent to 'big-endian.  The separate procedures are
provided as shorthand for when you want to write code portable across
different endians, and also to allow for a faster implementation on
big-endian machines.  This is biased in favor of big-endian machines;
an alternative would be to have three sets of procedures with no
optional argument:

  read-<int>  ; native
  read-be-<int> or read-network-<int>
  read-le-<int>

> 3. I think it must be possible to interchange port and endian, i.e.
>
>    (read-binary-uint32 port endian) should be just as possible as
>    (read-binary-uint32 endian) (or even (read-binary-uint32 endian port)?)

I don't see any need for this since you can already pass #f as the
port:

  (read-binary-uint32 #f endian)  ; read from (current-input-port)

> 4. Why aren't there any primitives to do binary string writing and
>    reading, or even binary buffer reading and writing?

Apart from further conflicting with possible binary/character port
distinctions, this is beyond the scope of this SRFI.  A general text
parsing library with procedures for reading delimited or terminated
strings with an optional size limit would be the right place for this.

--
Alex