Forum: Ruby Immediate Values

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-01 08:08
(Received via mailing list)
On Dec 31, 2005, at 10:07 PM, Johannes Friestad wrote:
> Fixnums and a few other special types (symbols, true/false/nil,
> floats?) are assigned as immediate values: Instead of storing a
> pointer (or reference) to the value object, the variable stores the
> value directly. So in
> a=4
> 'a' does not hold a reference, technically speaking, but rather the
> immediate value 4.
> This is an implementation issue, and is done for efficiency.

I understand that this is the standard explanation for this sort of
thing but does anyone else feel that it doesn't quite fit?  If
Fixnums can have instance variables then doesn't it make more sense
to think of a as containing a reference to the Fixnum object known
as 4?

In what way does a contain the value 4?

$ irb
irb(main):001:0> a = 4
=> 4
irb(main):002:0> a.object_id
=> 9
irb(main):003:0> 4.object_id
=> 9

I'm pretty sure that it is the object ids that are stored in variables
not the associated values.  Ruby of course doesn't actually allocate
space
for Fixnums but instead encodes the state of the referenced Fixnum in
the
object_id itself.  It can do this because Fixnum state is completely
encoded by its identity (i.e., its object_id).

I know I'm being pedantic (again) but I'd rather think of assignment
as *always* copying references.  It is simpler that way.  The
fancy bit-twiddling/implementation issues really come into play
when the variable is dereferenced not when assignment occurs.  At least
that is the way I've come to think about it.  Does anyone else think
about
it that way?

Gary Wright
Fe57662c550fb3cce44c398ddf2dd706?d=identicon&s=25 itsme213 (Guest)
on 2006-01-01 08:54
(Received via mailing list)
<gwtmp01@mac.com> wrote in message
news:8C1EA245-472B-4C94-9750-064CB61494BA@mac.com...

> I know I'm being pedantic (again) but I'd rather think of assignment
> as *always* copying references.  It is simpler that way.  The
> fancy bit-twiddling/implementation issues really come into play
> when the variable is dereferenced not when assignment occurs.  At least
> that is the way I've come to think about it.  Does anyone else think
> about
> it that way?
>
> Gary Wright

Some do (including me), but others don't find it useful. e.g. See

http://groups.google.com/group/comp.lang.ruby/brow...
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2006-01-01 14:22
(Received via mailing list)
On 1/1/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> On Dec 31, 2005, at 10:07 PM, Johannes Friestad wrote:
> > So in
> > a=4
> > 'a' does not hold a reference, technically speaking, but rather the
> > immediate value 4.
>
> I know I'm being pedantic (again) but I'd rather think of assignment
> as *always* copying references.  It is simpler that way.

You're describing the user model, I was talking about the
implementation. Immediate values are objects for (almost) all
practical purposes, so whether you think of fixnums as references to
immutable singleton objects or as immediate values doesn't make much
difference.
And as you say, it's simpler to use the same model for everything,
which is why many languages go to quite some lengths to hide the
difference.

I tend to think of programming languages (Ruby, C, assembler) as user
intefaces for the computer hardware. That makes 'usability' an
important factor for programming langauges, and supporting simple (but
still powerful) user models for how the language works is one aspect
of usability.
Implementation details are IMO mostly relevant for explaining why
there are two classes for integers (fixnum and bignum) in the first
place, or for that matter why there are 'integers' and 'floats'
instead of simply 'numbers'. In day-to-day programming, they rarely
matter.


jf
This topic is locked and can not be replied to.