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
> 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.
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
> 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)
you have to have:
i = 1
while (i< 10)
puts i; i +=1
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.
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
a = 1
b = 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
I have seen no convincing argument as to why ++ is not supported in Ruby.
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?