[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Names and primitives in SRFI 56

This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.

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>

> 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

  (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.