From: Gary Wright <gwtmp01@...>
Date: 2007-08-08T07:03:00+09:00
Subject: Re: Question - Passing parameters by reference


On Aug 7, 2007, at 5:18 PM, dblack@rubypal.com wrote:
> You're using the term "reference" in two different ways, though:
> first, as a synonym for a literal constructor (the actual "ink on the
> page", so to speak), and second as the thing bound to an object.

Perhaps that was just sloppiness on my part.  I think of a 'reference'
as the bit pattern that some particular Ruby implementation uses to
identify an object.  The point I was trying to communicate is that I
view literals such as
	1
	42
	true
	false
	:blue

as syntactical constructs that map directly to the particular bit
pattern that the Ruby interpreter uses to reference the associated
objects.  I think of them as 'literal references' as opposed to
'literal objects' or 'literal values'.  I'm not claiming that I'm
using any sort of accepted terminology.  I'm just trying to
communicate how I think about these things.

> But consider something like:
>
>   a = "blue".to_sym
>
> or
>
>   x = 10 + 10
>
> The literals :blue and 20 never occur, but a and x are in exactly the
> same state they'd be in if I'd done:
>
>   a = :blue
>   x = 20
>
> So my variables must be bound to something other than a reference, if
> "reference" means the those literals.

Well, I guess my point is that the Ruby interpreter, as part of its
parsing job, must convert :blue as found in the source code to
whatever internal representation of a symbol reference it is going to
use and similarly for 20 (and nil, false, true).

The fact that the conversion can be done at *parse* time rather than
later on at execution time point out how :blue and 20 are distinctly
different than 'hello' and [1,2,4], which can only be converted to
object references at runtime since it involves instantiating new objects
every time the code is executed.

> I guess I'd say that:
>
>   :blue
>   "blue".to_sym
>   10 + 10
>   20
>
> etc. are expressions (rather than references), and that every
> expression evaluates to an object.

And I would say that they are all expressions that evaluate to object
references.  Are you are saying that those particular expressions are
special because the 'standard' behavior is to return an object instance
that happens to be encoded right in the value of the reference
vs. some indirection into the heap?  That is an implementation detail.
Surely I could write a version of the Ruby interpreter that actually
allocated an object from the heap for Fixnums.  It would be slow and
it would have to ensure that there was only one 1 and one 2 and so on
but that implementation could still implement the same language  
semantics.

> Then there's the question of what
> happens with assignment.  I'm not sure how "canonical" the notion of
> the universal reference is (not just as a matter of implementation) --
> but it probably doesn't matter too much either way as long as
> (im)mutability and uniqueness, which are really object properties, are
> clear.

I agree with the uniqueness point but I'm not so sure about  
immutability.
Fixnums can have instance variables...

> My only concern is cases where the fact that something is an
> immediate value might explain some behavior that might otherwise seem
> unclear or pointless (like the ++ operator case).

But there is always all sorts of hand waving about assignment semantics
that include different rules for 'regular' objects and for 'value'
objects (nil, true, false, Fixnum, Symbol).  If you view 1 as a value
(i.e. an object) then you have to have those different rules to explain
how everything works.  If you view 1 as a reference to an object (even
if the object is a virtual object whose creation is 'optimized' away
via some creative bit-twiddling) then you don't have to have all those
different rules.  I like that.