Let's start with portability. I have ST/X, VAST, VW, Squeak, Pharo, GST, Dolphin, and some minor systems. GST and ST/X do not define #at: on any kind of integer at all. Why would they? #basicAt: will do the job, will it not? Dolphin defines #at:[put:] on Integer as self shouldNotImplement and so does VW. In VAST, 20 at: 1 => primitive failed 20 factorial at: 1 => 2192834560 In Squeak and Pharo, 20 at: 1 => not indexable 20 factorial at: 1 => 0 So sending #at: to an integer is not portable between mainstream Smalltalk systems, and for those Smalltalks that define it on large integers, the value is not consistent on the same machine and operating system. But it is worse than that. Maybe you do not care about any Smalltalk but Pharo, and there is a case to be made for that. But this is not consistent with *itself*. 1000000000000 at: 1 fails in a 64-bit VM, where that is a SmallInteger, but answers 0 in a 32-bit VM, where that is a LargePositiveInteger. But it gets *worse*. Numbers are not supposed to be mutable. But in a 32-bit VM, x := 1000000000000. x at: 1 put: 77. x => 1000000000077. I'm sorry, but I had enough grief with constants that weren't in Fortran 66. Again, there isn't the slightest need to define #at:put: on Large...Integers because #basicAt:put: exists. Indeed, we have #{basicAt:,at:,digitAt:}[put:] and surely with #digitAt:[put:] around we can let #at:[put:] be unimplemented on integers? There's a conceptual problem with #at: and #digitAt: as well. An integer can be viewed as a sequence of bits, right enough, but in a language without silly machine-word limits on integers, it's an *infinite* sequence. At least, if you define logical operations on bignums using a 2s-complement model, a LargePositiveInteger extends infinitely far with 0s and a LargeNegativeInteger extends infinitely far with 1s. GST gets this right. VW gets it right for large positive integers but wrong for large negative ones (or at least works on the absolute value without bothering to explain that). Ah heck, the whole thing is a mess. On Wed, 13 Mar 2019 at 17:18, K K Subbu <kksubbu.ml@gmail.com> wrote:
On 12/03/19 9:25 AM, Richard O'Keefe wrote:
Squeak where (20 factorial at: 1) answers 0 (oh dear oh dear oh dear).
Richard,
Could you please elaborate on why this is an error?
Large integers are place value encoded (base 256 little endian) and stored in byte arrays, so they need #at:/#at:put: (as private methods). Place value encoding is not architecture-specific so it doesn't affect portability of an image.
Regards .. Subbu