RFC: syntax for VM offsets: @, +, or [Oo] ?

[Rocky Bernstein]

Right now, to specify a VM offset in the trepanning debuggers, one prefaces a number with O or o.  

For example, a popular offset is o0 or O0, the beginning of a method. For example, in the "break" command:

   break IRB.start o7

breaks at VM bytecode position 7 rather than say line 7. (I use that sometimes because there is a bug in stopping at the beginning of some functions.)

However in displaying positions, I've been using @ in front of a number. For example

   -- (/usr/local/bin/irb:9 @2)

                                  ^^

   require "irb"

   (trepan): 

The Rubinius reference debugger uses + where I use @ in a traceback. For example 

   0xbfcc0b58: Integer#times in kernel/common/integer.rb:122 (+39 jit)

                                                                                            ^^^

   0xbfcc0dd0: __block__ in /tmp/sleep.rb:3 (+11)

                                                                 ^^^

I'm considering dropping the [Oo] prefix in favor of @ in the next releases. I'm probably the only one who has used this feature so the incompatibility isn't a problem. But if I'm wrong or you really favor one form over the other, lemme know.

   

[Roger Pack]

in order of preference for me:
 +39
 @2
 O7

[Rocky Bernstein]

Here is my concern with using +. 

In other commands +<integer> is the same as <integer>. For example in the up, down and list, and bt commands. The plus is allowed because we allow minus to go from the other direction. So " frame -1" sets the current frame to the oldest frame, and "break +12" is the same thing as "break 12", In fact you an even write "break 10+2"  but I'm not sure how useful that is.

Given this would, that change things? That is: would making + to mean offset in some commands but a sign value be confusing? I can also start disallowing +<integer> various commands. 

The case against using @ for offset, is that @ isn't quite the same here as in assembly. As Rubinius seems to suggest, it is an offset not a pointer or a memory address. 

It would be good to here from others before changing. I'm not opposed to making the change to +, but it would be nice to get more feedback first.