From: dblack@...
Date: 2007-08-08T07:28:09+09:00
Subject: Re: Question - Passing parameters by reference

Hi --

On Wed, 8 Aug 2007, Gary Wright wrote:

> I wrote: 
>
>> 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?

No, I really meant to lump all expressions together, pretty much.  I
probably should have thrown in some non-symbol/integer ones.

> 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...

I'm not sure what the right terminology is for the thing that you
can't change in Fixnums, Symbols, etc.  Basically I mean the fact that
you can't turn 1 into 2, even though you can embellish 1 with state.

>> 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.

I'm thinking more about variables than literals, though, because
that's where the questions arise.  It's easy to see that 1++ is
meaningless; but it's harder, I've found at least, to explain why:

   x = 1
   x++

wouldn't make sense, without recourse to explaining the immediate
presence of 1 in x.

I'm certainly in the market for continuing to think this through, as
I'm always interested in ways to explain what Ruby is doing in the
most expressive way possible.  It's only when I think that people will
get *more* confused, rather than less, without it, that I trot out the
immediate value stuff.  It's definitely not in the interest of pushing
implementation details into view; it's more a matter of accounting for
the semantics of the language and the behavior of its methods (things
like ++ and why one can't append to symbols).


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)