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

Re: Names and primitives in SRFI 56

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.

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