Ruby doesn't implement x++ for Fixnum's because ???
in [Ruby]
|
Prev: Thread error "undefined method `keys' for nil:NilClass"
Next: Getting version from PE executables
From: Joel VanderWerf on 8 Nov 2009 23:54 Tony Arcieri wrote: >> 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? 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. -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
From: Tony Arcieri on 9 Nov 2009 00:15 [Note: parts of this message were removed to make it a legal post.] On Sun, Nov 8, 2009 at 9:54 PM, Joel VanderWerf <vjoel(a)path.berkeley.edu>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. 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"... -- Tony Arcieri Medioh/Nagravision
From: Ralph Shnelvar on 9 Nov 2009 01:39 > Never mind, bar= was still defined because I was reopening the class. Noob question: What does that mean?
From: Tony Arcieri on 9 Nov 2009 01:44 [Note: parts of this message were removed to make it a legal post.] On Sun, Nov 8, 2009 at 11:39 PM, Ralph Shnelvar <ralphs(a)dos32.com> wrote: > > Never mind, bar= was still defined because I was reopening the class. > > 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... -- Tony Arcieri Medioh/Nagravision
From: Marnen Laibow-Koser on 9 Nov 2009 06:36
Tony Arcieri 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 marnen(a)marnen.org -- Posted via http://www.ruby-forum.com/. |