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

On 2009-11-09, Tony A. [email protected] wrote:

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

Tony A. wrote:
[…]

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

Really?

Well, that’s certainly one of the issues.

[…]

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,

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On 2009-11-09, Joel VanderWerf [email protected] wrote:

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

Marnen Laibow-Koser wrote:

Tony A. wrote:

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,

Marnen Laibow-Koser

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… :slight_smile:

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

On 2009-11-09, Marnen Laibow-Koser [email protected] wrote:

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

On 2009-11-09, Tony A. [email protected] wrote:

[Note: parts of this message were removed to make it a legal post.]
On Sun, Nov 8, 2009 at 9:54 PM, Joel VanderWerf [email protected]wrote:

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

-s

Seebs wrote:

On 2009-11-09, Marnen Laibow-Koser [email protected] wrote:

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.

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

-s

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On 2009-11-09, Marnen Laibow-Koser [email protected] wrote:

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

On Mon, Nov 9, 2009 at 8:40 AM, Seebs [email protected] wrote:

I’d rather see “++count”. It’s easier for me to read.

Hey, I might ‘rather’ have C allow if statement modifiers.

And I might ‘rather’ have French do away with all those pesky gender
agreements and thinking of towers as feminine and a lap around a track
as masculine.

But they don’t, and I find I can live with that, and I certainly have
been much happier with Ruby even without a++ or ++a than I ever was in
C/C++, and I am, or at least was, competent enough in C to do things
like writing compilers in it, and reading and understanding the Ruby
source code etc.

This whole thread is reminding me of Mark Twain’s complaint about the
stupidity of the French, because he “never could get them to
understand their own language!”


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Rick Denatale wrote:

On Mon, Nov 9, 2009 at 8:40 AM, Seebs [email protected] wrote:

I’d rather see “++count”. �It’s easier for me to read.

Hey, I might ‘rather’ have C allow if statement modifiers.

And I might ‘rather’ have French do away with all those pesky gender
agreements and thinking of towers as feminine and a lap around a track
as masculine.

But they don’t, and I find I can live with that,

Ce n’est pas la même situation. Nous anglophones ne pouvons pas changer
la langue française tout d’un coup. Mais nous pouvons changer Ruby si
nous en avons besoin.

and I certainly have
been much happier with Ruby even without a++ or ++a than I ever was in
C/C++,

Mais oui!

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On 2009-11-09, Rick DeNatale [email protected] wrote:

But they don’t, and I find I can live with that, and I certainly have
been much happier with Ruby even without a++ or ++a than I ever was in
C/C++, and I am, or at least was, competent enough in C to do things
like writing compilers in it, and reading and understanding the Ruby
source code etc.

I’d rather use Ruby without those features than C++ with them. (Not
quite
so sure about C, but certainly there’s plenty of things for which I’d
rather
use Ruby than C.) But on the other hand, I really do like the syntactic
sugar.

My favorite syntactic sugar ever was Icon’s swap operator. Sure, you
don’t
need it often, but it sure is nice to be able to express it so clearly.

-s

Marnen Laibow-Koser wrote:

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

Marnen - I tried to do this:
a = [1,2,3,4]
a.each do |b|
puts b
b % 2 == 0
end

But it … Predictably … (?) showed me 1, 2, 3, 4, each on a separate
line. Was your example sarcasm, or is that actually a Ruby construct?

Je vous en prie, ne nous moquons pas de la langue francaise, qui est une
langue, apres tout, tres belle et subtile, et qui peut etre imbue de
douceur comme de violence avec de simples changements de nuance.

Aldric G. wrote:

Marnen Laibow-Koser wrote:

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

Marnen - I tried to do this:
a = [1,2,3,4]
a.each do |b|
puts b
b % 2 == 0
end

But it … Predictably … (?) showed me 1, 2, 3, 4, each on a separate
line.

Because you used a different method than I did.

Was your example sarcasm, or is that actually a Ruby construct?

No sarcasm. You just failed to notice that I wasn’t using .each. :slight_smile:

Je vous en prie, ne nous moquons pas de la langue francaise, qui est une
langue, apres tout, tres belle et subtile, et qui peut etre imbue de
douceur comme de violence avec de simples changements de nuance.

Je ne me moquais point de la langue française ! Je ne voulais que dire
qu’il est beaucoup plus possible de changer la langue Ruby que de
changer la langue française.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Aldric G. wrote:

Marnen Laibow-Koser wrote:

Aldric G. wrote:

Marnen Laibow-Koser wrote:

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

a = [1,2,3,4]
b = 0

‘nip’ is undefined outside the block

irb(main):393:0> b = a.size do |nip|
irb(main):394:1* puts nip * 2
irb(main):395:1> nip > 6
irb(main):396:1> end
=> 4
irb(main):397:0> b = a.size do |nip|
irb(main):398:1* puts nip * 2
irb(main):399:1> nip < 6
irb(main):400:1> end
=> 4

I don’t understand this block.

You’re using Array#size. I’m using Enumerable#count. They’re not
interchangeable.

Aussi, si je puis me permettre - le Francais est une langue, et Ruby est
un langage (de programmation). Yet another one of those french
subtleties!

Merci ! Je ne le savais pas.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On Mon, Nov 9, 2009 at 6:30 AM, Aldric G. [email protected]
wrote:

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

The only reasons it’s impossible are cultural, not technical. If you
think
there’s a valid technical reason why it’s “impossible” to implement
perhaps
you’d care to state it.

On 2009-11-09, Tony A. [email protected] wrote:

The only reasons it’s impossible are cultural, not technical. If you think
there’s a valid technical reason why it’s “impossible” to implement perhaps
you’d care to state it.

It’s impossible to implement as a method. You could introduce it as
syntactic sugar, but it’s not so clear that this would be worth the
trouble. In particular, incrementing is inefficient in Ruby because
it would involve creating many new objects to iterate.

-s

Tony A. wrote:

The only reasons it’s impossible are cultural, not technical. If you
think
there’s a valid technical reason why it’s “impossible” to implement
perhaps
you’d care to state it.

Tony, as I said: I am merely a fledgling Ruby enthusiast. I’m reading
“Best Practices in Ruby” and had to tape my jaw to my skull so it would
stop falling off.
This being said, YOU are welcome to implement the ‘++’ operator and let
us know how it works. I can tell you’re vastly more knowledgeable than I
am (yet! I will catch up to you! mwa ha ha!), so please show us.

Marnen Laibow-Koser wrote:

Aldric G. wrote:

Marnen Laibow-Koser wrote:

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

a = [1,2,3,4]
b = 0

‘nip’ is undefined outside the block

irb(main):393:0> b = a.size do |nip|
irb(main):394:1* puts nip * 2
irb(main):395:1> nip > 6
irb(main):396:1> end
=> 4
irb(main):397:0> b = a.size do |nip|
irb(main):398:1* puts nip * 2
irb(main):399:1> nip < 6
irb(main):400:1> end
=> 4

I don’t understand this block.
Aussi, si je puis me permettre - le Francais est une langue, et Ruby est
un langage (de programmation). Yet another one of those french
subtleties!

Hi –

On Tue, 10 Nov 2009, Aldric G. wrote:

a = [1,2,3,4]
irb(main):400:1> end
=> 4

I don’t understand this block.
Aussi, si je puis me permettre - le Francais est une langue, et Ruby est
un langage (de programmation). Yet another one of those french
subtleties!

http://dablog.rubypal.com/2007/4/17/the-l-in-dsl-langue-ou-langage

:slight_smile: (Not the same topic obviously but your comment made me think of
it.)

David


The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

David A. Black wrote:

Hi –

On Tue, 10 Nov 2009, Aldric G. wrote:

Aussi, si je puis me permettre - le Francais est une langue, et Ruby est
un langage (de programmation). Yet another one of those french
subtleties!

http://dablog.rubypal.com/2007/4/17/the-l-in-dsl-langue-ou-langage

:slight_smile: (Not the same topic obviously but your comment made me think of
it.)

Actually, David, I believe that you are right on the mark with that
reference :slight_smile: