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

Re: Names and primitives in SRFI 56

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

OK, Sorry, I didn't know that.

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

Hmm. I'm not sure I agree on that. Binary I/O simply means there's
no interpretation given to the I/O; As I see it, the primitives 
to write and read provide the interpretation (see also my earlier 
e-mail about doors and what goes through them).

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

That's OK with me, but let's start with such an SRFI right away,
because A binary i/o srfi without primitives for character strings
seems to me a littlebit, ah how does one say that in english, "disabled?".

> --
> Alex

Hans Oesterholt-Dijkema