Ruby doesn't implement x++ for Fixnum's because ???

[Joshua Ballanco]

=20
=20
What exactly is it you think I'm "incorrect" about?

I apologize, but I feel the need to interject:

http://xkcd.com/386/

...that is all.

- Josh=

 

[Marnen Laibow-Koser]

What exactly is it you think I'm "incorrect" about?

The last assertion you made about the ++ operator. Read the recent
posts from Seebs and others. Make sure you understand them.

Best,

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

The last assertion you made about the ++ operator. Read the recent
posts from Seebs and others. Make sure you understand them.

I read and responded to them. Was there something about my responses you
didn't like, aside from my initial confusion with a dangling method from a
previously defined class?

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

I apologize, but I feel the need to interject:

http://xkcd.com/386/

I still find this most appropriate:

http://bit.ly/w8WZA

 

[Phrogz]

Never mind, bar= was still defined because I was reopening the class.

Dude, you just about gave me a heart attack. Phewsh - sanity is
restored.

 

[Gavin Sinclair]

I suppose the whole discussion is moot as Ruby will likely never see a ++
operator.

I was just trying to make clear the limitation wasn't a technical one, and
further show how a ++ operator could be "Ruby-like" while still retaining
C/C++/Java-like semantics.

If implementing ++ requires changes to the parser, that seems like a
pretty technical limitation to me!

Matter of interpretation?

BTW in all your posts on the topic, you don't seem to address pre-
increment vs post-incrememt. (Forgive me if I'm wrong.) If Ruby
implemented ++ and didn't address that, it wouldn't be C or C++
semantics at all.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

Dude, you just about gave me a heart attack. Phewsh - sanity is
restored.

My bad, it will serve as a reminder to double check my work before posting

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

If implementing ++ requires changes to the parser, that seems like a
pretty technical limitation to me!

Assuredly it would require changes to the parser, as "++" presently
lexes/parses as "plus (unary+ value)", and that's not to mention how it
parses in method definitions. The resulting operation is equivalent to
binary +, unless you're using something like

BTW in all your posts on the topic, you don't seem to address pre-
increment vs post-incrememt. (Forgive me if I'm wrong.) If Ruby
implemented ++ and didn't address that, it wouldn't be C or C++
semantics at all.

That's a can of worms I've been trying to avoid, as there are lexing/parsing
ambiguities surrounding the combination of both. How do you parse a+++b vs
a++++b vs a+++++b?

 

[Joel VanderWerf]

That's a can of worms I've been trying to avoid, as there are lexing/parsing
ambiguities surrounding the combination of both. How do you parse a+++b vs
a++++b vs a+++++b?

The only sane answer is to do what C does, as far as parsing. But the
deeper problem in ruby is what do pre- and post- really mean? In C there
are expressions and there are other constructs, so we can define natural
boundaries for pre and post in terms of expressions. In ruby we have
mostly expressions. So the hard questions are "before what?" and "after
what?"

Does

foo {x++}

yield the incremented x to foo, or the original x? What if foo yields
several times? Increment once, or once per iteration?

What about

x = 0
y = case; when true; x++; end

Is y 0 or 1?

It's kind of an ink-blot test for what you think "expression" means, but
of course everything is an expression in ruby.

It's not an answer to say

'x++' should have the same effect as 'x+=1'

because that's not even true in C.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

The only sane answer is to do what C does, as far as parsing.

You will find the answer to these edge cases varies. Fortunately they are
edge cases...

But the deeper problem in ruby is what do pre- and post- really mean?

Really?


In C there are expressions and there are other constructs,

As someone intimately familiar with the expression/statement barrier, I
really don't see the issue...

so we can define natural boundaries for pre and post in terms of
expressions. In ruby we have mostly expressions.

Ruby is a pure expression-based language (and I see you acknowledge that
later in this message). There are no statements which don't return a value.

So the hard questions are "before what?" and "after what?"

Does

foo {x++}

yield the incremented x to foo, or the original x?

Well, to be pedantic, foo is yielding. The return value of the block in
this case is original x.

What if foo yields several times? Increment once, or once per iteration?

Once per iteration.

What about

x = 0
y = case; when true; x++; end

Is y 0 or 1?

0


It's kind of an ink-blot test for what you think "expression" means, but of
course everything is an expression in ruby.

Funny, earlier you implied there were things that aren't expressions in Ruby

It's not an answer to say

'x++' should have the same effect as 'x+=1'

because that's not even true in C.

Correct, it's ++x that would have the same effect as x += 1, not that I find
the preincrementation vs postincrementation distinction particularly useful
in Ruby, which is why I've advocated picking the canonical one and going
with that, even though preincrementation has semantics which would make more
sense in Ruby.

I'm trying to be pragmatic... and yet being dismissed out of hand. Because
it is not Ruby-like! According to certain people's definitions of
"Ruby-like"...

 

[Ralph Shnelvar]

Never mind, bar= was still defined because I was reopening the class.

Noob question: What does that mean?

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

Noob question: What does that mean?

Before defining either of the classes I described, I did this:

class Foo
attr_accessor :bar

...
end

This meant Foo#bar= was defined already. I forgot I did that, and thus my
results were, well, unexpected...

 

[Marnen Laibow-Koser]

Tony Arcieri wrote:
[...]

Really?

Well, that's certainly one of the issues.

[...]

Correct, it's ++x that would have the same effect as x += 1, not that I
find
the preincrementation vs postincrementation distinction particularly
useful
in Ruby,

The "step through subscripts" use of ++ and -- is not useful in Ruby
because of the use of iterators. The pre-/postincrement distinction is
not that useful because of the nature of the language. So...why have ++
and -- at all if its two main advantages are not useful in Ruby?
Where's the benefit? What is some actual Ruby code that would be
improved by these constructs?

which is why I've advocated picking the canonical one

There is no one canonical one. Pre and post are both canonical, and
that's the problem.

and going
with that, even though preincrementation has semantics which would make
more
sense in Ruby.

Um, what?

I'm trying to be pragmatic...

What's pragmatic about grafting onto Ruby a feature which is useful in C
but not in Ruby?

Again, if you can think of an actual context where this would be useful
in Ruby, please provide actual code.

and yet being dismissed out of hand.

You're not being dismissed out of hand. You've been given numerous
reasons why this is not a great idea, which it seems that you keep on
ignoring.

Because
it is not Ruby-like! According to certain people's definitions of
"Ruby-like"...

The fact that it would require major parser and language changes is a
pretty good indication that it is not in keeping with the nature of the
language...

Best,

 

[Seebs]

That's a can of worms I've been trying to avoid, as there are lexing/parsing
ambiguities surrounding the combination of both. How do you parse a+++b vs
a++++b vs a+++++b?

Maximal munch. Those are, in order:
a++ + b
a++ ++b (a syntax error)
a++ ++ +b (also a syntax error)

But I think the more difficult issue is the semantics.

-s

 

[Seebs]

Does

foo {x++}

yield the incremented x to foo, or the original x? What if foo yields
several times? Increment once, or once per iteration?

Postincrement should always produce the original value.

What about

x = 0
y = case; when true; x++; end

Is y 0 or 1?

0, of course. postincrement gives the original value. I would say that,
by the end of the assignment to y, x has taken the value 1, but what's yielded
by a postincrement is not the value of x, but a separate value which happens
to be the same as the value x used to have.

It's not an answer to say

'x++' should have the same effect as 'x+=1'

because that's not even true in C.

Right. But that is (nearly always) what "++x" should mean.

Hmm.

Let us imagine that we were to make ++ a rebinding operator, like +=. Not
just for Numerics, but always -- otherwise we lose the expected semantics.
Hmm. This leads to an interesting point:

Since you can't modify the underlying object when it's immutable, it violates
POLS for ++ to ever modify the underlying object. It would ALWAYS be a
rebinding to a new value.

The semantics of "++x" would indeed be exactly equivalent to "x += 1". The
semantics of "x++" would be equivalent to
magic_temporary_value = x
x += 1
magic_temporary_value

The question is...

Would this be useful enough to justify the hassle? I'm not sold on it.
The postincrement form is really primarily useful for idioms that don't
make any sense in Ruby. The preincrement form is actually sorta nice,
because it really is easier for me to read (I don't have to actually
think about whether the amount incremented by is really 1 or not). I'm
not sure it's nice enough to justify the effort.

-s

 

[Aldric Giacomoni]

The fact that it would require major parser and language changes is a
pretty good indication that it is not in keeping with the nature of the
language...

Best,

I really do hesitate to speak, here, as I am not nearly as skilled in
Ruby, or C / C++, as the rest of you, but it seems to me that Matz
expressed his opinion on the matter already...

Also, in more productive terms:
"a += 1".size => 6
"a+=1".size => 4
"a++".size => 3
RubyForum::Thread.self.count_keystrokes => zomg !

On the other hand, it's also plain impossible to implement, for various
reasons listed numerous times prior to this humble message.

It seems to me that at this point, the next and only logical step is to
take the Ruby source code and go implement whatever you want to
implement.. Then come back with your own language, which may well be
called Lapis-Lazuli, and will allow the ++.

 

[Seebs]

[Note: parts of this message were removed to make it a legal post.]

The only sane answer is to do what C does, as far as parsing.

You will find the answer to these edge cases varies.

No, you won't. The parsing is 100% consistent and has been, so far as I
know, in every compiler released since the mid-70s.

Ruby is a pure expression-based language (and I see you acknowledge that
later in this message). There are no statements which don't return a value.

But "expressions" can be extremely large.

In C, "x++" yields the current value of x, and at some point between the
prior sequence point and the next sequence point, x gets incremented.
The reason that "i + i++" is *undefined behavior*, not just an unspecified
value, is that Deep Magic may occur to implement or support the
increment operators. There's no particular guarantee -- none at all --
that such code even runs, let alone does anything specific.

That's fine. C has "sequence points", and because expressions in C are
pretty simple and limited, you always have plenty. Consider:

for (i = 0; i < 10; ++i) {
printf("%d\n", i);
}

The evaluation of each of the control expressions in the for loop is
separated from everything else by sequence points. There's a sequence point
between the evaluation of i for the printf and the actual execution of
printf, and another when printf is done, and so on.

Let's look at a while loop to simplify a bit:
i = 0;
while (i++ < 10) {
printf("%d\n", i);
}
In C, that should consistently yield the numbers 1 through 10. (When i
is 0, i++ is < 10, but increments i, so printf sees 1. When i is 9, i++
is 9, thus still < 10, but increments i, so printf sees 10.)

In Ruby, if you did something similar to this, you might write:
i = 0
while i++ < 10
puts i
end

When, exactly, do we expect that the increment happens? This whole thing
is an expression. I'm not aware of anything particularly equivalent to
sequence points. Do we ensure that i is incremented before puts is called?
Consider that this whole block (while ... end) could be a single argument
to a function, because it's just an expression.

In short, the fact that control statements in Ruby are also expressions
makes it harder to run with the simple "by the end of the expression"
heuristic most people use.

Think about:

puts i++ || i

In C, you'd have a nice solid guarantee that the increment happens before
the || (because &&/|| are sequence points). Would you in Ruby? I have no
clue.

Correct, it's ++x that would have the same effect as x += 1, not that I find
the preincrementation vs postincrementation distinction particularly useful
in Ruby, which is why I've advocated picking the canonical one and going
with that, even though preincrementation has semantics which would make more
sense in Ruby.

There's nothing particularly more canonical about postincrement. It is
the one that's harder to replace by just writing something else. I would
rather see both, personally. In particular, it looks very much as though
postincrement would be expensive, so I'd want preincrement available so
I could actually use it.

-s

 

[Seebs]

Where's the benefit? What is some actual Ruby code that would be
improved by these constructs?

blahblahblah.each do |args|
lots of stuff lots of stuff
if condition
count += 1
end
end

I'd rather see "++count". It's easier for me to read.

-s

 

[Marnen Laibow-Koser]

blahblahblah.each do |args|
lots of stuff lots of stuff
if condition
count += 1
end
end

I'd rather see "++count". It's easier for me to read.

Would you? Or would you rather see
count = blahblahblah.count do |args|
lots_of_stuff
condition
end
?

-s

Best,

 

[Seebs]

Would you? Or would you rather see
count = blahblahblah.count do |args|
lots_of_stuff
condition
end

Huh! That is prettier. Didn't know it existed.

But in general, basically, any place where we have a += 1, I'd prefer ++.

And I am pretty sure that +=1 is occasionally useful.

-s