This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
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