leppie wrote: > Given a custom port has get/set-position procedures, it could be done > easily (I am not entirely sure I can depend other those procedures > though), but without either, what should the behavior be? What happens > with the get-xxx prodedures after a lookahead-xxx has been called? Is it > up to the implementer to provide some 'wrapper/proxy' port to provide > these indirectly?
Implementors of the R6RS are responsible for making that work even if the custom port does not support get-port-position and set-port-position!. That wouldn't be hard, except there are three distinct bugs in the design of R6RS custom ports that make the R6RS impossible to implement (or to implement sensibly) for certain cases. As specified by the R6RS, custom implementations of get-port-position cannot work reliably, because there is no way for a buffered port to tell the custom implementation about the current position within a buffer, and all ports use lookahead buffering at the very least. (This comes up in the situation leppie cited, when a lookahead-xxx is followed by a get-xxx.) Similarly, custom input/output ports cannot work reliably in general, because there is no way for the i/o system to tell a custom port to correct for a lookahead byte or character when switching from input to output. Thirdly, and more broadly, all textual input/output ports whose transcoders use variable-width encodings (or use end-of-line styles other than none) have problematic and/or partially undefined semantics. Output operations that overwrite a character (or end-of-line) with a character whose encoding is of a different length have undefined semantics. All three of these bugs have been documented for some time in Larceny's list of deprecated R6RS syntax and procedures [1]. Will [1] https://trac.ccs.neu.edu/trac/larceny/wiki/DeprecatedR6RSSyntaxAndProcedures _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
