[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Names and primitives in SRFI 56

This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 are here. Eventually, the entire history will be moved there, including any new messages.



At Mon, 27 Sep 2004 22:03:48 -0700, Dale Jordan wrote:
> 
> A number of Schemes (Scheme48 and Chicken, at least) support
> byte-vectors for doing aggregate binary io.  This seems to satisfy most
> needs for doing something beyond simple scalar io, while still allowing
> the application to perform whatever interpretation is necessary.
> 
> I suppose some might consider it onerous to require implementing such a
> data type for this SRFI, but I consider byte-vectors extraordinarily useful.

Would these be equivalent to SRFI-4 u8vectors and SRFI-47 au8 arrays
(which have the comment "Byte arrays can be implemented independently
and distinctly from strings")?

I did consider utilities to read/write directly to/from these data
types, but came across a few stumbling blocks.  First, there are two
competing SRFIs.  Second there is the question of interface - do you
provide separate procedures on each type:

  (read-u8block! u8vec port)    ; fill u8vec from port, SRFI-4 style
  (read-u16-block! u16vec port)
  ...

or do generic dispatch on type:

  (read-array! u8vec port)      ; fill u8vec from port, SRFI-47 style

With generic dispatch the reference implementation becomes slow and
non-extensible.  This would still be my preference, but it's enough
added complexity that I would rather it go in a separate SRFI.
Basically all I wanted for SRFI-56 was to make binary I/O *possible*
via 4 primitives and throw in some useful library procedures that
wouldn't really be controversial.

Regardless, this feature is orthogonal to the current debate which is
that *if* you allow binary operations (including potentially
operations on byte arrays), can you perform said operations on all
ports and if not how do you designate for a given port if it supports
binary vs character operations?  I'm sorry for the delay, I really
haven't come up with any better ideas, so when I release an updated
version (RSN) the API will become (with hopefully better wording):

  ;; new port predicates, not necessarily disjoint

  (binary-port? port)
  (character-port? port)

  ;; new procedures such that the port generated is guaranteed to
  ;; return #t for BINARY-PORT?, whereas the R5RS equivalents always
  ;; return #t for CHARACTER-PORT?.

  (open-binary-input-file file)
  (open-binary-output-file file)
  (call-with-input-binary-file file proc)
  (call-with-output-binary-file file proc)
  (with-input-from-binary-file file thunk)
  (with-output-to-binary-file file thunk)

READ-CHAR, WRITE-CHAR, READ, WRITE, DISPLAY and all other R5RS I/O
procedures are guaranteed to be allowed on any port for which
CHARACTER-PORT? returns #t, assuming all other qualifications are met
(i.e. you're not trying to read from an OUTPUT-PORT?).

READ-BYTE, WRITE-BYTE, PEEK-BYTE and BYTE-READY? plus the library
procedures provided in SRFI-56 are guaranteed to be allowed on any
port for which BINARY-PORT? returns #t, assuming other qualifications
are met.

String ports are guaranteed to return #t for at least CHARACTER-PORT?.

Implementations are free and encouraged to make no distinction between
the port types, while program authors are encouraged to use the
*-binary-* equivalents for port creation when they don't intend to
perform any character-level operations, both for portability and as a
reminder of the purpose of the port.  When both binary and character
operations are to be used, the R5RS procedures are preferred.

-- 
Alex