Peter,

A few comments on the current draft of SRFI 281:

1. “Should native-endianness be a procedure or a value? The R7RS Large
usually does not have procedures like this …”  But R7RS Small does
(e.g. ‘jiffies-per-second’, which is another system-information
accessor like ‘native-endianness’).  I think it’s fine for this to be
a procedure.

2. I would be happy to see more procedures from SRFI 207 added and
brought into line with SRFI 152.  I’m not sure why so many procedures
from the bytestrings SRFI are missing start & end arguments.

3. “All procedures in this SRFI return newly allocated containers …”
All procedures in this SRFI that return containers at all return
newly-allocated ones.  (Pedantry, I know.)

4. Apparently (srfi 281 u8) exports ‘bytevector-s8-ref’ and
‘-s8-set!’ but not the ‘u8’ forms.  Typos?

5. “If this library is voted into R7RS Large, then all features are
supported, (scheme bytevector) must be the composite library, and
(scheme bytevector) not have any sublibraries.”  I’m not sure I
understand this sentence.

6. “The R6RS only has the static endianness macro, which cannot be
portably implemented in syntax-rules.”  How is it any easier to
implement ‘endianness?’ portably, if it accepts implementation-defined
symbols?

Also, if you only care about the identifiers ‘big’ and ‘little’,
the macro is easy to write:

    (define-syntax endianness
      (syntax-rules (big little)
        ((endianness big) 'big)
        ((endianness little) 'little)
        ((endianness e)
         (syntax-error "invalid endianness" e))))

It seems to me the portability issue here is knowing the full set of
endianness symbols, not whether they’re handled with a macro or a
procedure.  But maybe I’ve misunderstood.

(I’m similarly confused about why ‘error-handling-mode’ can’t be
implemented portably if you only care about the three identifiers given
in the SRFI.)

7. “[The serialization procedures] are no longer required to signal
errors.”  Why the change?  In another context, SRFI 281 says that
“error-raising behavior is more natural” than pushing on through
invalid elements.  Is there some rationale for signaling errors when
decoding Unicode but not when decoding hex- or base64-encoded data?
(I’d prefer signaling in these cases, too.)

That’s all I have for now.  Thanks very much for your work on this
SRFI.  It puts together a lot of important pieces.

Wolfgang

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>