On 2009-11-08, Tony Arcieri <tony@[...].com>  wrote:
>  I can't think of a language where "variables are objects".

I'd say they are in C.

In C:
	{
		int x;
	}

x is an object.  There is storage which is reserved for x, which is not
associated with any other object, etcetera.  Modifications "to x" always
affect this specific object; you can't make x be some other object, all
you can do is change its contents.

>  And this isn't
>  the issue.  The real issue is Numeric values (i.e. "objects") are
>  immutable.  Other types of objects, however, are mutable.  "Everything is an
>  object", except some objects are different than others.

I think it is the issue though.

The reason you can write "x = x + 1" in Ruby, but not "x++", is that you
have to modify the variable, not the object.  If x was previously the Fixnum
1, you don't want to change 1 to 2 -- you want to change x to point to a
different object.  You can't do that by sending x a message, though, you
have to write it in the code that knows about the variable x.

>  Advocates of allowing a ++ operator are suggesting that the operator have a
>  dispatch model which alters the local binding when applied to Numeric
>  types.

(1+2)++

1+2 =>  the Fixnum 3

What is the local binding which gets incremented?  There's no variable there,
only an object.

>  What I really see happening here is that ++ reveals an otherwise
>  difficult-to-see difference in how immutable and mutable objects behave in
>  Ruby.  There's no reason Ruby can't have ++, but it would need special case
>  behavior, because the behavior of Numerics is already a special case.  Any
>  ugliness surrounding special-case behavior of ++ when implementing it
>  against Numerics stems from this inconsistency in Ruby itself, not the ++
>  operator.

I don't entirely agree.  The difference is most *obvious* with Numerics,
but it's true of just about anything.

Imagine that we define ++ on an array as equivalent to "a = a + [ nil ]".
That is, it appends a new value on the end of the array.

Now try setting up an array:
	a = Array.new
	b = a
	a++

How many items does b have?  Why, it now has an item, because there is only
one array.  a and b are not arrays; a and b are variables which hold
references to a single array object.

What that means is that, while Numerics have special case behavior, *the
special case behavior is the one we actually want*.

Ignore the return value for a moment.  Clearly, the *intent* of "a++" is
the same as the *intent* of "a = a + 1".  But in Ruby, those aren't the
same thing.

	a = Array.new
	b = a
	a = a + [ nil ]

This makes a and b into two separate objects.

>  It's not that I doubt the pragmatism of the immutability of Numeric values
>  (on the contrary, I'm developing a language where *all* values are
>  immutable), but this is really the cause of the problem, and the solution
>  (special casing how Numerics respond to ++ by providing alterations to the
>  local binding) causes me no qualms, as it's only a workaround of the
>  separation of immutable/mutable objects that's a fundamental part of Ruby to
>  begin with.

I disagree, because I think it would violate POLS to have ++ work differently
on numerics, when clearly, that behavior (alters local binding) is exactly
what we want... Probably.

Again, I really think the root of this is that ++ is designed for a language
in which the variable is its own object, not a reference to another object.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@[...].net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!