Comment 1 for bug 251642

On Jul 24, 2008, at 3:05 PM, Michael D. Adams wrote:

> I think you got some of the arithmetic in accounting for custom port
> buffers backwards.

I agree that this is incorrect, but what's the correct behavior?

On the one hand, the IO system can fully keep track of the position
since it knows how many bytes have been read into the buffer and how
many bytes have been consumed by get-u8, so, the port position is
always known. (this is how the file-based ports know their position;
they never use lseek or whatever to compute the current position)
So, can port-position simply bypass the given procedure and always
return some internally computed value?

Either way, we can get this to work for binary ports since the given
procedure is required to return an integer and with some arithmetic
we can get the right answer. But what about textual ports? Since
the get-position procedure may return "a single value" without any
restrictions on what that value may be, we cannot use that value to
compute the actual position of the port. It seems that we cannot
buffer custom textual ports. But we have to buffer at least one
character to support lookahead-char! In that case, we have to get
the port position before we do a lookahead-char, cache it just in
case we get asked for it, and throw it away when we do a get-char.
So, can the implementation call the supplied get-position procedure
before lookahead-char and even if the user did not call port-positon?

Any ideas for how to resolve this interesting problem?