Some comments relating to ICFP contest

[Andre van Tonder <andre@xxxxxxxxxxxxxxxxx>]

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.