Names and primitives in SRFI 56

["Hans Oesterholt-Dijkema" <hdnews@xxxxxxxxx>]

Dear SRFI-56 members,

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.

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.

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

4. Why aren't there any primitives to do binary string writing and
   reading, or even binary buffer reading and writing? Suppose I want
   to read in a Bitmap? Suppose I want to read in strings without inter-
   pretation?

   I think following constructs would be great:

   (read-binary-string size port encoding) 

      where 

   size : size of string in characters counted in the given encoding.
   encoding <-- { ascii, latin1, latin2, ..., utf8, utf16, unicode, ...}

   (write-binary-string string port [encoding])

      where

   encoding <-- { CURRENT, ascii, latin1, ... }

   Also, I think the following blob constructs could be of great help:

   (read-blob size port)

   (write-blob obj [size] port)

   But I think, these will introduce maybe new data types in scheme.
   But see how they could facilitate interesting things:

   (define p (open-input-socket xyz))
   (define size (read-binary-uint32 p))
   (define jpeg (read-blob size p))

   (gui-display-bitmap device-context jpeg)

   (...)


Best whishes,
--
Hans Oesterholt-Dijkema