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: Seebs on 9 Nov 2009 08:15 On 2009-11-09, Tony Arcieri <tony(a)medioh.com> 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 -- Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on 9 Nov 2009 08:21 On 2009-11-09, Joel VanderWerf <vjoel(a)path.berkeley.edu> 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 -- Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Aldric Giacomoni on 9 Nov 2009 08:30 Marnen Laibow-Koser wrote: > Tony Arcieri 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... :) 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 ++. -- Posted via http://www.ruby-forum.com/.
From: Seebs on 9 Nov 2009 08:32 On 2009-11-09, Tony Arcieri <tony(a)medioh.com> 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 <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. 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 -- Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on 9 Nov 2009 08:33
On 2009-11-09, Marnen Laibow-Koser <marnen(a)marnen.org> 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 -- Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! |