I have a few comments based on my experience in trying to implement the
ICFP contest virtual machine specification using Scheme.  I found that most
Schemes were pretty much useless for this particular application, being severely
handicapped by the following issues.

- No support for 32-bit or 64-bit integers.
- No support for unsigned 32-bit/64-bit arithmetic, including unsigned division.
- No support for bit operations on 32-bit or 64-bit quantities.
- No support for uniform unboxed arrays.

I was surprised that these types are not more commonly represented, since their
implementation would come almost for free in many architectures.  They
are awkward and expensive to simulate otherwise, and their absence inhibits
communication with languages that have them.

Also, I would imagine that many practical applications of bit-twiddling are
most useful on multiples of 8 bits.  I see little point in even having these
operations on fixnums with a non-portable range.

I think portability would be greatly aided by requiring these specific types,
perhaps in addition to the fixnum types required by the SRFI.  As for the
latter, I do understand the reason for their having less than 32 bits on most
implementations, but given this, in the absence of a precise specification of
their range (as opposed to the current lower bound), it is unclear to me how the
specification will contribute to portability, not to mention issues of formal
semantics and correctness, when the meaning of a fragment
of numeric code is allowed to be implementation-dependent.

Another comment:

- I see <digit-16> admits only lowercase a to f.  This is not a problem
   when writing new code, but may be a pain when inputting or copying
   existing hex numbers.  Many (most?) hex numbers out there are
   in uppercase.