On 8/23/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> wrote:
>
> Alex Shinn <xxxxxx@gmail.com> writes:
>
> > I wasn't actually suggesting Schemes supporting SRFI-68 voluntarily
> > restrict themselves in this manner, I meant rather to show what the
> > problem is along with a more concrete solution implemented using
> > SRFI-68, like using a hash-table to implement a vector.
>
> Understood.  I meant to say that I didn't understand your solution.

Ah, OK, I kind of hand-waved it.

Assuming a strict binary/character port distinction, we could effectively
read size-delimited strings out of a binary port by having SRFI-56
require support for READ-BLOB-N on binary ports, and using something
like:

  (define (read-binary-string-n port n)
    (blob->string (read-blob-n port n)))

or alternately just call it READ-STRING-N and have it dispatch and
handle both binary and character ports.  N would be defined in terms of
bytes - you'd need a similar procedure to read NULL terminated strings,
easily done by scanning bytes at a time until a zero byte occurs and
accumulating the results in a blob.

BLOB->STRING would be implementation dependent but could
be defined easily in SRFI-68 as

  (define (blob->string blob)
    (read-string-all (open-blob-input-port blob)))

For the time being SRFI-56 could either leave the character encoding
of binary ports unspecified, or else specify a default of UTF-8,
possibly allowing an optional encoding argument to BLOB->STRING.

Although we're considering using the same procedure name and
letting READ-STRING-N work on any port type, this is still much
simpler than allowing arbitrary character I/O on binary ports,
because it avoids the state problems (one can assume the port
is in the "default" state before and after the extracted string) and
it doesn't allow single character reading, which involves
complications such as knowing where character boundaries are
for all encodings and potentially skipping ahead state changing
bytes.

--
Alex