[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Names and primitives in SRFI 56
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
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.