Earlier I said: > But I think this shouldn't be TOO bad to implement. You're right that if we > use ONLY lookahead we can't do it. but I don't think that should be a > problem. In particular, in our current code, in sugar.scm's function > readblock-internal...
Hmm, that approach might not work, but I just realized there's a *much* simpler approach: use unread-char(). All we need is one-character unread-char, and it's trivial to implement. unread-char() *is* in at least guile (at least 1.8) and in ChezScheme (http://practical-scheme.net/wiliki/schemexref.cgi?ChezScheme). It's not a standard R5RS operation, but since the C standard does require ungetc() with at least one-char pushback, I wouldn't be surprised if other Schemes support it (or could be talked into it). Guile supports unlimited pushback, ChezScheme supports 1-char pushback; we only need 1 char. If we need to port it to Schemes without unread-char(), we could create a thin portability layer to add unread-char support (by creating a special "port" that stores any 1-char unread, which would only be the period if used). The code in modern.scm has to handle leading period specially anyway, in process-period, and the first thing *IT* does is get the char (which undoes any unread-char of a period), so it shouldn't change much of the rest. --- David A. Wheeler ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
