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 3 Nov 2009 23:24 On 2009-11-04, Rick DeNatale <rick.denatale(a)gmail.com> wrote: > Why this wierd semantic? Because it the original use case was for > pointers rather than integers, and it goes back to C originating > originally as a kind of high level assembly language for the DEC > PDP-11 which had postincrement and predecrement addressing modes used > for stepping through strings or arrays. Apparently apocryphal -- the increment usage predates the PDP 11 port of C. (Interestingly, there's now a ton of sources repeating the story, but so far as I know, the canonical answer from Ritchie and Thompson was that the increment operator predates C proper, and thus the PDP 11 work.) > Because pre-ANSI C allowed easy spoofing/overlay of types, it also > worked for integers and was used in contexts like for loops > for(i = 0; i < max;i++) It is not because of spoofing or overlay of types that this worked, but because the operator's defined for all types. > If you want the real semantics of the C/C++ post-increment operator, > I'm afraid you'll have to look for it in a C family language, not an > object reference semantic language like Ruby. This part, though, I totally agree with. It's not coherent to imagine a ++ operator, especially a postincrement, working in a Ruby-like language. -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: Michael W. Ryder on 4 Nov 2009 00:29 Tony Arcieri wrote: > [Note: parts of this message were removed to make it a legal post.] > > On Fri, Oct 30, 2009 at 12:03 PM, Rick DeNatale <rick.denatale(a)gmail.com>wrote: > >> I think that theres a more fundamental problem with ++ in a language >> like ruby, which has to do with the difference between objects and >> variables. >> > > Personally I see nothing interesting about the behavior of ++ in any mutable > state language. > > >> Now, consider not immutable objects, but defining ++ for a mutable >> object. I've named the method plus_plus instead of ++ since I can do >> the former, but not the latter. >> > > How is ++ any different from << except for << taking an argument? (given > hypothetical C-like ++ behavior) > Maybe I am missing something but how would one print a variable and increment it with the same statement? In C one would just write printf ("%i/n", x++). I haven't seen any easy way to do this with Ruby. Using << or +=1 you have to have a separate statement for the assignment. So instead of having something like: i = 1 while (i < 10) puts i++ end you have to have: i = 1 while (i< 10) puts i; i +=1 end I can see a reason for not being able to do 2++, but not i++. > There is already extensive precedent in Ruby for destructive method calls > that mutate state, and they all lead to the same confusion. > > There is nothing interesting with Ruby in this regard, except that Ruby does > seem to go out of its way to do things immutably by default, which, in my > opinion, is pretty cool. But in the end Ruby is still very much a mutable > state language. >
From: Tony Arcieri on 4 Nov 2009 00:38 [Note: parts of this message were removed to make it a legal post.] On Tue, Nov 3, 2009 at 10:30 PM, Michael W. Ryder <_mwryder55(a)gmail.com>wrote: > Maybe I am missing something > Yes, maybe you're missing that I support a unary ++ operator :) I can see the wisdom in not having it there to begin with though. I see the ++ operator as something almost inextricably tied to for loops in C. Ruby provides better looping mechanisms, like the various Enumerable methods that take blocks! Perhaps Matz didn't include a unary ++ operator as encouragement to use better looping constructs in your code. If that's the case, I think he certainly succeeded. -- Tony Arcieri Medioh/Nagravision
From: Charles Oliver Nutter on 4 Nov 2009 01:58 Of course I had to jump in here. Yes, a++ and ++a could easily be rewritten by the parser into the appropriate increment+set of a and the expression either returns the incremented value or the non-incremented value. And I would like to see that added. It doesn't fundamentally change the expectations of the programmer, and it provides a one-character-shorter version of a+=1. There's really no reason it shouldn't be added, because even in Java or C, you are *never* modifying arbitrary references to that value...you are *always* re-assigning the value a given variable points to. This example: a = 1 b = a a++ Would cause exactly the same results in every language I've worked with...b would be 1 and a would be 2. The ++ operator never modifies a value, it modifies what value the variable has assigned to it. If it were modifying a value, then using ++ to bump a pointer through memory offsets would have horrible side effects for anyone else assigned that pointer value. I have seen no convincing argument as to why ++ is not supported in Ruby. - Charlie
From: lith on 4 Nov 2009 04:24
> Yes, a++ and ++a could easily be rewritten by the parser into the > appropriate increment+set of a and the expression Wouldn't it be cool if ruby had macros? |