Alex Shinn <xxxxxx@gmail.com> writes:

>   * separate procedures to write text to binary ports
>     - something like read/write-utf8-string
>     - Java takes this approach letting you read and write UTF-8
>       characters to binary ports.
>     - a complete API would need to handle all encodings.
>
>   * procedures to convert strings to and from srfi-4 uvectors or blobs
>
>   * separate mixed binary+text ports
>     - open-binary-and-character-input-file
>     - wouldn't have guarantees about buffering efficiency
>
>   * layered ports
>     - open a character port on top of a binary port, read/write a value,
>       close the character port then continue using the binary port
>     - flexible but more than we need for simple assembler-type cases

You have seen that SRFI 68 addresses all of these issues, right?

> Or, finally, I could simply withdraw the SRFI and considering writing up
> a new one [...]

I still think your SRFI is quite useful, as it supports more
binary-data types than SRFI 68.  I'd personally prefer if SRFI 56 were
built on top of SRFI 68, which should be quite easy, but whatever you
decide, I'd recommend sticking with it.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla