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.
Alex Shinn <alexshinn@xxxxxxxxx> 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