Re: Ruby's implementation of Fixnum-assignment

On Dec 21, 12:26=A0pm, Robert Klemme <[e-mail]> wrote:
> 2009/12/21 RichardOnRails <[e-mail]>:
>
> > I've made the following observations about Ruby's apparent
> > implementation:
>
> > 1. Integer's in the range -2**30 to 2**30-1 are Fixnum's. Integers
> > outside that range are Bignum's
> > 2. For Fixnum "i", =A0i's object_id is twice i's value plus 1. =A0Said
> > another way, i's object_id is i''s binary value left-shifted with 1 as
> > padding.
> > 3. Object_id's of Bignum's close to the boundaries of Fixnum's bear no
> > apparent relationship to the Fixnum object_id's.
>
> All correct.
>
> > These observations suggest to me that an assignment statement like
> > "a=3D1" requires the interpreter to do no more than:
> > 1. =A0Search for the identifier "a" in the current scope.
> > 2. =A0If found, use it; if not, enter it in the current scope and then
> > use it.
> > 3. "Use it" means take the binary representation of the assigned
> > value, =A0left shift it with "1" padding, and make that current
> > object_id of the identifier "a".
> > 4. There is no need to locate free space in an memory pool where
> > object values for Bignums, Strings and other object are stored. =A0For
> > Fixnums, the object_id IS the value, just a little shifted.
>
> > Is my speculation about this aspect of Ruby's implementation correct,
> > or am I all wet?
>
> Hm... =A0While you have many things right, I don't fully agree. =A0No
> variable (be it a local variable like "a" in your example or an
> instance variable like "@a") has an object id. =A0Object id is a
> property of an object which might be referenced by many variables.
> Your step 3 actually mixes two separate things: evaluation of the
> expression of the right side of "=3D" and assignment. =A0"Using" in an
> assignments means to take whatever the expression spits out and store
> it in the variable.
>
> Now, what your right hand expression yields is an object reference.
> For optimization purposes some object references are special in that
> they actually *are* the object (these are the "immediate values" which
> Gary mentioned, Fixnums for example). =A0This does not make special
> treatment for assignments necessary. =A0Rather, it makes special
> treatment for _method calls_ necessary. =A0Because then the interpreter
> does not have to look up the object on the heap etc.
>
> Someone with more intimate knowledge of the implementation might be
> able to explain this better. =A0But I believe it's important to point
> out that the difference is not in the assignment but in the right hand
> side expression which - in the case of a Fixnum - yields a special
> object reference.
>
> Kind regards
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestp=
ractices.com/

Hi Robert,

> No variable ... has an object id.

Robert,  I know, by virtue of reading a number of your responses in
this NG, that you=92re a Ruby expert.  But the statement referenced
above is contradicted by at least two authorities on Ruby:
1. =93... every object has a unique object identifier (abbreviated as
object ID)=94 [=93Programming Ruby=94,  Second Edition, Thomas, et al, p.
12] , where you praised the book=92s usefulness :-).   Of course, the
=93id=94 method has since be deprecated to =93object_id=94 when we want to
reference an object ID.
2.  =93... an object in Ruby has an identity: =93abc=94object_id
#53744407
This object ID is of limited utility." [=93The Ruby Way=94, Second
Edition, Fulton, p.26]

> step 3 actually mixes two separate things: evaluation of the expression o=
f the right side of "=3D" and assignment

Granted, I stuck to what I viewed as the essential issues.  Perhaps a
more complete estimate might read.

3.1	Ruby interprets =93a =3D 1=94 to mean =93a.=3D(1)=94, i.e.  invokes the=
 =93=3D=94
method on the object.  Normally, that reference will cascade up to
Object.=3D, I suppose.
3.1a  If =93a=94 is undefined in the current scope, =93a=94 will be added t=
o
the scope with an ID of (2a+1) =3D 3.
3.1b Otherwise:
3.1.b.1 If a=92s ID is in the range of Fixnums, (or a=92s ID indicates
it=92s true, false, etc .), a=92s ID will be set to 3
3.1b.2 Otherwise, if a=92s ID indicates any other type, a=92s ID will be
pushed to the garbage stack and a=92s ID will be set to 3
Is that better?

> For optimization purposes some object references are special in that they=
 actually *are* the object

That sounds like you mean in the case of Fixnum =931=94,  that the number
1 IS the ID as well as the value of the object.  But we can see =93puts
1.object_id=94 =3D> 3
So I think that fact (plus all the other evidence I offered) suggests
that ID=92s for Fixnum=92s are manufactured as 2*value+1
QED???

As always, thanks for your insightful response.
Richard