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