Am 07.01.2012 um 07:04 schrieb Ben Coman btc@openInWorld.com:

I had thought that the two assignments of 'xxx' to (x) and (y) would result in different objects, but they turn out to be identical. It is like the compiler has noticed that they are equal and chosen to make them identical.

That is indeed what's happening.

You can verify this by executing each line separately.

- Bert -

Ben Coman <btc <at> openInWorld.com> writes:

Thanks Bert. Doing that is insightful.  Interestingly the result is different with numbers.  Where strings assigned in separate executions are not identical, numbers assigned in separate executions are identical - at lower values.  For example, number 12345678 has (x) and (y) identical but with 123456789 they are not.  I then expected those number literals to be a different class, but both numbers inspect as SmallIntegers.  btw this is with Pharo-1.3-13315-cog2522.  Anyway, my curiosity is satisfied for now. cheers, Ben

I was about to invite you to dig a bit deeper in the system in order to satisfy your curiosity, but it's a bit harder than I imagined...

You could start your search with a method finder looking matches of *literal* One should deserve your attention, Encoder>>encodeLiteral: You will see it uses an inst. var. named litSet. If you browse references to it, you'll see it is initialized with StdLiterals class var. in Encoder>>#initScopeAndLiteralTables You can inspect this class var and see it is a PluggableDictionary (not a set as the litSet name did tell). If you browse references to StdLiterals, it is indeed initialized in VariableNode class>>initialize with StdLiterals := PluggableDictionary new equalBlock: [ :x :y | x literalEqual: y ].

So finally, we get it, the method of interest is #literalEqual: If two literals are literally equal, then only one is created. I encourage you to understand why 2, 2.0s1, 2.00s2 and 2.0 are not literally equal, though they arithmetically are

Of course, why is Encoder a subclass of ParseNode (an Encoder is not a ParseNode !), why a class variable used exclusively in Encoder is initialized in VariableNode, would be very good questions. The implementers did choose inheritance just to share a few class variables, and this is not a very clean design. Even the indirection #name:key:class:type:set: is rather arguable, it factors code of two senders at the price of a complex interface (5 parameters is way too much), and thus at the price of readability. But hey, why do you think some people started to write a NewCompiler ;) Also, anti-patterns are also a very good way to learn how to (not) code, so in its way these are good lessons for noobs.

Nicolas

On Sat, 7 Jan 2012, Ben Coman wrote:

Bert Freudenberg wrote:

Am 07.01.2012 um 07:04 schrieb Ben Coman btc@openInWorld.com:

I had thought that the two assignments of 'xxx' to (x) and (y) would result in different objects, but they turn out to be identical. It is like the compiler has noticed that they are equal and chosen to make them identical.

That is indeed what's happening.

You can verify this by executing each line separately.

Thanks Bert. Doing that is insightful. Interestingly the result is different with numbers. Where strings assigned in separate executions are not identical, numbers assigned in separate executions are identical - at lower values. For example, number 12345678 has (x) and (y) identical but with 123456789 they are not. I then expected those number literals to be a different class, but both numbers inspect as SmallIntegers. btw this is with

That's impossible, SmallIntegers with the same value are identical.

Levente

Pharo-1.3-13315-cog2522.

Anyway, my curiosity is satisfied for now. cheers, Ben

On 08.01.2012, at 00:48, Ben Coman wrote:

For some naive reason I thought that the SmallIntegers would stop at 64k.

No, SmallIntegers currently use the full 31 bit range:

{SmallInteger maxVal hex. SmallInteger minVal hex} ==> #('16r3FFFFFFF' '-16r40000000')

Is it platform dependent on whether the CPU is 16/32/64 bit ?

Squeak is independent of the CPU word size. All images in general use are 32 bits. That means an object pointer (aka "oop") is a 32 bit word. Squeak's ancestor, Smalltalk-80, used 16 bit oops. For Squeak there is an experimental 64 bit image format, where each object pointer uses 64 bits. (1)

Normally an oop references a chunk of memory, which has one to three header words, and zero or more words for the "contents" of the object.

Only SmallIntegers are special: their oops do not reference memory, but the value is taken from the bits of the oop itself. Each oop has one "tag" bit which determines if it is a normal oop (a reference) or an "immediate" object. The other 31 bits determine the value of the SmallInteger. (2)

That's why two SmallIntegers with the same value are always identical. "==" simply compares oops.

- Bert -

(1) "64 bit VM" means a VM compiled for a 64 bit processor, "64 bit image" means an image that use 64 bit oops. These are independent concepts, a 64 bit VM may run a 32 bit image. See http://squeakvm.org/squeak64/faq.html

(2) There have been proposals to use more tag bits, which would reduce the range of SmallIntegers, but add more immediate classes. There have been experiments but nothing has been officially adopted yet. But in particular with 64 bit oops there are so many bits that we may see more immediate classes.