For what it's worth, I think that it may be time to look at
using the square bracket characters [] which R5RS reserves.

I realize that lots of people are using them for things that
aren't arrays and that this will break code which uses them
in that wise; but I think that arrays are the natural and
obvious use for these characters.

I dislike srfi-58 (and several earlier srfi's) for being
incompletely specified w/r/t machines of architectures where
the given "hardware types" make no sense.

For example, if I'm running scheme on a PDP-11 which has
18-bit halfwords and 36-bit words, and which uses a float
representation that has no simple mapping to IEEE1178 32-bit
floats, how am I supposed to implement this?  Conversely, if
a new CPU becomes popular in 10 years that uses 56-bit floats
and integers in a tagged architecture with 8 bits of a 64-bit
word reserved for tags, how will this srfi be meaningful?

Many recent RISC processors have no 8-bit operations.  Some
in the fairly near future will probably also lack 16-bit
operations.  It would be far more efficient for these
systems to allocate 16 bits where an 'au8' is requested;
is it legal for them to do so?  Was 'au8' a minimum number
of bits to be provided, or must it be *exactly* 8 for purposes
of this SRFI?

IOW, are we looking at these things for internal use (in which
case a minimum bit count is appropriate) or is this aiming at
FFI on 32-bit Intel processors (in which case an exact bit count
is appropriate and we may as well specify the endianness)?

Are we specifically giving scheme developers quasi-numeric
binary types in which they can *RELY* on getting round-off and
wraparaound phenomena of particular kinds at particular thresholds?
And if so do we require any scheme systems to simulate exactly
those roundoffs and those wraparounds regardless of the
underlying hardware architecture?

I think that would be a preposterous thing to do.

Scheme, IMO, needs ways to handle array rank and multi-index
array reference; but the mapping of hardware types to scheme
types is best left for a declaration syntax that can be given
a syntax-rules definition that makes it simply "disappear" on
systems where the SRFI isn't implemented.  On systems that
do implement the hardware type mappings, roundoffs and
wraparounds may occur.  But we should give scheme implementors
latitude to use *at least* that many bits by noting that it is
still an error in scheme programming to rely on them.

			Bear