[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
> (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
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?".