Hi :) On Sun 24 Feb 2013 21:14, Mark H Weaver <m...@netris.org> writes:
> Andy Wingo <wi...@pobox.com> writes: > >> On Sat 28 Jan 2012 11:21, Mark H Weaver <m...@netris.org> writes: >> >>> The R5RS specifies that if 'char-ready?' returns #t, then the next >>> 'read-char' operation is guaranteed not to hang. This is not currently >>> the case for ports using a multibyte encoding. >>> >>> 'char-ready?' currently returns #t whenever at least one _byte_ is >>> available. This is not correct in general. It should return #t only if >>> there is a complete _character_ available. >> >> This procedure is omitted in the R6RS because it is not a good >> interface. Besides its semantic difficulties, can you think of a sane >> implementation for multibyte characters? > > Maybe I'm missing something, but I don't see any semantic problem here, > and it seems straightforward to implement. 'char-ready?' should simply > read bytes until either a complete character is available, or no more > bytes are ready. In either case, all the bytes should then be 'unget' > before returning. What's the problem? The problem is that char-ready? should not read anything. If you want to peek, use peek-char. Note that if the stream is at EOF, char-ready? should return #t. Andy -- http://wingolog.org/
