> Should it, or should we change the specification to use an R6RS
condition type?  So far the SRFI is written in R7-ese, but condition
types are probably the way forward.

I would prefer keeping it portable to both, at least for the time being.

Perhaps it can be kept as "an error is signaled": then an R6RS system
can raise an &assertion violation and an R7RS system can do whatever
sensible thing the implementer wants. That would also keep the door open
for more exotic extensions, like continuing execution by feeding it
bytes from the handler.

 > I'm going to go with John's idea here, I think--either it's undefined
to mutate the result or, as R6RS would have it, the result is "an
immutable bytevector" (and mutating it SHOULD be an assertion
violation).

OK with me, as long as it's explicit.

 > I am strongly of the opinion that this SRFI shouldn't provide any
procedures for drawing random data.  The idea is to build all of
that on top, probably with this structure:

 >    SRFI 194
 >    --------
 >    SRFI  27   ↑  This way up.
 >    --------
 >    SRFI 217

I'm OK with that, but it should be made a little more explicit,
particularly when comparing it to SRFI 27.

-- Peter McGoron