This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
I have a few comments based on my experience in trying to implement theICFP 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.