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

Some comments relating to ICFP contest



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.