Question - Passing parameters by reference

On Aug 6, 2007, at 8:16 PM, Logan C. wrote:

this seemed to illustrate it better in my head. Seeing it typed
out, it
doesn’t look so insightful. I guess what I’m trying to say is.
don’t think
of literals as ways of referring to objects, think of them as
method calls
that return objects. Or something like that.

It is confusing to me to even think about methods returning objects
unless
you are using that as a very specific shorthand for saying that methods
return references to objects. That is the unifying idea that
helped me
understand how Ruby manipulates data–it is all references and not the
objects themselves. The objects themselves are almost completely hidden
from the programmer (excluding C extensions) in Ruby. Everything is a
reference to an object. At least that is the way I have come to
understand
things but it means that you have to ditch the idea that Fixnum’s and
Symbols (and true, false, nil) are somehow special cases. In my mind
they
are not. The literals :blue, 42, true, false, nil are all references to
particular objects and assignment is the process of binding a
reference to
a variable.

Of course I’m not talking about the underlying implementation that
Ruby
uses to make this all efficient. I’m talking about the abstract
semantics
of Ruby’s object model.

Gary W.

On Aug 6, 2007, at 3:28 PM, [email protected] wrote:

I’d agree about the literal 1 in comparison with other literals:

1 # textual representation of that object
“hi” # textual representation of that object
[1,2,3] # etc.

In the way I think about things those examples are not the same.

An integer literal is a representation of a constant
reference to a particular object. It doesn’t matter
how many times the literal appears in the text, it will always
refer to a particular object, in this case the Fixnum instance that
behaves like the integer 1. There is no object creation involved
when an expression like 1 or 42 is encountered by Ruby unlike your
second two examples.

“hi” is special syntax for constructing a brand new
instance of String and [1,2,3] is a special syntax for constructing
a brand new instance of Array.

(1…10).map { 1 } # array has 10 identical references
(1…10).map { “hi” } # array has 10 different references

but if you do this:

a = 1
b = “hi”

now a (as I understand it) is actually bound to the integer 1, while b
is bound to a reference to the object. (I can’t say “A reference to
‘hi’” since that ‘hi’ would be a different one… :slight_smile:

The way I think about this is that

a = 1

binds a to the reference for the Fixnum instance 1. And in

b = “hi”

the right hand side causes a new instance of String to be
instantiated and
the reference to that new instance is bound to b.

In both cases, the rhs evaluates to a reference, which is bound to a
variable. I like that symmetry.

Gary W.

On Aug 7, 2007, at 5:18 PM, [email protected] 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.

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.

Hi –

On Wed, 8 Aug 2007, Gary W. wrote:

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.

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

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

Hi –

On Wed, 8 Aug 2007, Gary W. wrote:

It is confusing to me to even think about methods returning objects unless
a variable.
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. 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.

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

David

Hi –

On Wed, 8 Aug 2007, Gary W. wrote:

presence of 1 in x.
with programmers (myself included) coming from other languages.
We try to find a place for it in Ruby when it isn’t really needed.

I don’t know – in my case, I just always remember reading and
learning that a = 1 resulted in a having the immediate value of 1
(specifically in Ruby, I mean). I have no instinct or incentive to
introduce or find a place for the concept if it isn’t there already.
My understanding, which could be wrong, is that that’s how things were
actually happening. And remember that the whole concept of an
“implementation detail” is relatively new in Ruby, since it’s only
recently that we’ve started dealing concretely with multiple
implementations and the whole set of issues surrounding what is and is
not a Ruby implementation.

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

Do those examples really require the introduction of immediate values?

Again, I can’t speak to the introduction point directly, because my
impression is that the immediate value thing is already there. But as
to the explanatory value – I’ve always reached for the immediate
value, unique, immutable explanation because I thought it was accurate
and it helped people understand what was happening and how to use the
objects. I’ve therefore never seen the need to look further. (Call
it “Black’s Razor”, or something :slight_smile:

I don’t know whether it’s necessary or not, though. It’s certainly
not a magic bullet, especially in the case of symbols.

[… various interesting ideas for other ways of explaining thigns
…]

Instead of using the immediate value abstraction though, the
situation can be explained by correcting the erroneous assumption
that fixnum objects are containers for an integer value that can
be changed. There is an extra level of indirection in the string
case that simply doesn’t exist in the fixnum case.

It’s interesting – I think it’s always about that extra level of
indirection, and perhaps just a matter of where one assigns it a place
in the diagram, so to speak.

David

On 8/8/07, Gary W. [email protected] wrote:
snip

It seems to me that the idea of immediate values is not something
inherent in Ruby’s semantics but instead is baggage that arrives
with programmers (myself included) coming from other languages.
We try to find a place for it in Ruby when it isn’t really needed.
snip

Gary W.

I open my sticker-plastered, procedural language steamer trunk:
“variable” in the Ruby world and find a toothbrush. This is not a
problem with Ruby just inappropriate baggage. Lately, I’ve tossed the
toothbrush in a dop kit named “appellative”. It’s easier to carry, at
least for me.

Michael Gaunnac

On Aug 7, 2007, at 6:28 PM, [email protected] wrote:

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.

Take a look at this message from Matz:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/20236.

I have to think about this a bit more, but it isn’t clear to me
why the concept of immediate values needs to be introduced in order
to explain the problems with x++ in Ruby.

It seems to me that the idea of immediate values is not something
inherent in Ruby’s semantics but instead is baggage that arrives
with programmers (myself included) coming from other languages.
We try to find a place for it in Ruby when it isn’t really needed.

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

Do those examples really require the introduction of immediate values?

Once you understand that there is a one-to-one mapping between Fixnum
instances and a subset of the integers it is clear why you can’t
‘increment’ a Fixnum instance. It is a nonsensical concept yet the
concept of ‘successor’ is well-defined.

Similarly once you understand that there is a one-to-one mapping between
Symbol instances and their ‘label’ it is clear why you can’t ‘append’
something to the label and still have the same symbol. The identity
of a Symbol instance is inherently tied to its label and it is that
isomorphism that makes Symbols useful.

I’m not sure how much more juice we can squeeze out of this orange but
looking back at this thread it seems that the OP was looking for a
way to change the ‘value’ of a Fixnum method argument in the same
way that the ‘value’ of a String method argument can be changed.
Cue the immediate value discussion.

Instead of using the immediate value abstraction though, the
situation can be explained by correcting the erroneous assumption
that fixnum objects are containers for an integer value that can
be changed. There is an extra level of indirection in the string
case that simply doesn’t exist in the fixnum case.

Gary W.