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