David A. Black wrote:
> Hi --
>
> On Mon, 3 Oct 2005, Robert Klemme wrote:
>
>> David A. Black <dblack / wobblini.net> wrote:
>>> Hi --
>>>
>>> On Mon, 3 Oct 2005, Robert Klemme wrote:
>>>
>>>> Pascal GUICHARD <pascal.guichard / gmail.com> wrote:
>>>>
>>>>> - on pointers, i try to understand (howto implement)
>>>>> datastructures in which you need to mix values and
>>>>> references/poiters
>>>>
>>>> You cannot use values in Ruby directly.  There are only
>>>> references. Think of Ruby as Java without POD's.  In practice
>>>> there are some
>>>> optimizations for Fixnums, Symbols and some other types but
>>>> conceptually (i.e. from a usage point of view) you never see values
>>>> directly. x = nil
>>>> x = Object.new
>>>> x = "foo"
>>>> x = 123
>>>>
>>>> Here "x" is always a reference variable - like every other variable
>>>> is a reference variable.  It's so simple but sometimes difficult to
>>>> get used to - especially when coming from other programming
>>>> languages.
>>>
>>> I think the "immediate value" status of Fixnums etc. goes beyond
>>> just being an optimization, though, and has some practical
>>> consequences
>>
>> Which?
>
> Mainly the explanatory thing :-)  But also the fact that:
>
>    a = :sym
>    b = :sym
>
> a and b are the same object.  I do realize, though, that this is not
> specifically a matter of immediacy of value, but more of uniqueness
> and immutability on the part of symbols.

IMHO the issue here is behavior of a certain type of expression.  Besides
the usual constructors (MyClass.new) Ruby has a number of other
expressions types built intp the language that return objects - sometimes
new objects (like with "foo", 'foo', [], {}) and sometimes the same (like
with 1, 2, 3, :sym).

>  I guess I don't have too
> many concrete ideas about it.... I've just always felt (though I
> realize you don't) that it's easier to understand the whole
> immediate/unique/immutable nature of integers, symbols, nil, true,
> false if one understands it all at the same time.
>
> Pretty non-technical, I admit.

I guess folks are different and what works for some best for me is likely
different from what works best for you.

>>> and
>>> even some explanatory power.  In particular, in:
>>>
>>>   x = 123
>>>
>>> x holds the immediate value 123, rather than a reference to it,
>>
>> But this does not make a difference from a usage point of view: for
>> doing x = x + 1 (or short x += 1) it doesn't make a difference.
>
> Right; I said *explanatory* power :-)
>
> [...]
>
>> Hm...  I don't know whether I can follow this argument.  *If* there
>> was a ++ operator in Ruby, it would probably be the equivalent of
>>
>> x++ <=> ($_,x=x,x.succ;$_)
>> ++x <=> (x=x.succ)
>>
>> Maybe Matz found this (especially in the first case) a too complex
>> construct to be hidden by this unary operator.  Dunno.  But at the
>> moment I fail to see how this unary operator relates to the fact of
>> "immediate values".
>
> Because if x actually *is* a number, then:
>
>    x = 1
>    x++
>
> suggests 1++, which makes no sense.  It's not that it could not be
> made to parse as x = x.succ or whatever; it's that (as I understand
> Matz's reasoning) x++ conventionally suggests an operation on a
> variable, which obscures the fact that in Ruby, a variable with an
> integer in it is exactly that integer object.
>
> Another way to put it is:  assuming that eventually people are going
> to learn that integers in variables are immediate values, having an
> overly-sugary x++ would give rise to people asking, "How can you
> increment an actual integer?"  Right now what happens is people ask,
> "Why can't you do x=1; x++ ?" and then they learn about immediate
> values :-)

I'll have to think about this a bit more.  Unfortunately I don't have the
time right now... :-(

Kind regards

    robert