[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: srfi-56@xxxxxxxxxxxxxxxxx
- Subject: withdrawal
- From: Alex Shinn <alexshinn@xxxxxxxxx>
- Date: Fri, 26 Aug 2005 10:53:30 +0900
- Delivered-to: srfi-56@xxxxxxxxxxxxxxxxx
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Tex2A5m5aYHoX0AZhbL1sfg4l+6g8NE6aZw1npECf4TAwTnN1+XYlNy4560qlj189EilZFqI662XLKPalnPgM9LXFi560ZhrTJevW2hTpumbtFLIkCQaHBlpPYQtBQdMs86FKIC3D2HnZSW39rCbt3Wn9tMH/ZTMygx46dDcMmk=
As it stands, SRFI-56 isn't useful for anything unless you
assume you can mix binary and textual I/O on the same
port. Therefore the addition of this distinction failed in its
purpose and currently just stands as a wart in the SRFI.
There are many ways to fix this, but it's not clear which
is the best. I'd like to rethink the issue from scratch, and
in particular wait for other current I/O SRFIs to complete.
This also means we can get rid of the current overflow
between the SRFI-56 and SRFI-68 lists. If you have
further comments on binary I/O, please join the SRFI-68
list and continue the discussion there.
Thanks everyone for you comments.