I see ISLisp fixed a huge 1997 gaffe in 2007. (Or perhaps earlier; these are all drafts). 1997 draft: "For eq, the consequences are undefined if either obj1 or

I see ISLisp fixed a huge 1997 gaffe in 2007. (Or perhaps earlier; these are all drafts). 1997 draft: "For eq, the consequences are undefined if either obj1 or obj2 is a number or character." 2007 draft: "For eq, the consequences are implementation defined if both obj1 and obj2 are numbers or both are characters." They are still neglecting the possibility of cleaning up the language here by not allowing that much implementation latitude. All Lisps should have a range of fixnum integers which are unboxed, and comparable with eq. Characters should also be unboxed and comparable with eq. It's also buggered in the following way: eq should be required to yield false if the arguments are such that eql would yield false. If the arguments are different numbers, or the same numeric value but of a differnt type, they cannot be the same object; eq should yield false. Also, what is "implementation defined"? Unfortunately, it is vague: "feature, possibly differing between different ISLISP processors, but completely defined for every processor". How is it defined, if this document doesn't define it? Every language spec that doesn't completely define everything should have both implementation-defined and unspecified behaviors. It should spell out that in those situations, failure is not an option: the behavior is chosen by the implementor from a set of possibilities. There should be a requirement that the implementation must be accompanied by a document which describes the implementation-defined choices. (For unspecified behavior, how the choice is made need not be documented.) What eq does with numbers is a great candidate for unspecified behavior. At least, if we accept the idea that two small integers like 1 and 1 could be different objects. If you give implementations that much latitude, just let it be unspecified so they don't have to commit to the details. Today, I would specify that the implementation must provide a range of integers called fixnums, and that two fixnums of equal value compare true under eq. I would also require that characters be comparable with eq. There is no need to cater to toy implementations which make every object a pointer to a boxed value in the heap. I would specify that fixnums go from at least -8192 to 8191. That allows for 16 bit objects to have 2 bit type tag, for really small systems. As a matter of orthography, the compound adjective implementation-defined should be hyphenated.