local vars clobbered by un-run code

Discussion in 'Ruby' started by Trans, Jun 19, 2007.

  1. Trans

    Trans Guest

    Err...

    irb(main):001:0> def x; 1; end
    => nil
    irb(main):002:0> p x
    1
    => nil
    irb(main):003:0> if false
    irb(main):004:1> x = x() + 1
    irb(main):005:1> end
    => nil
    irb(main):006:0> x
    => nil

    Don't tell me, it's some quirk of the way Ruby works. Sure looks like
    a bug though. Just in case:

    ruby 1.8.4 (2005-12-24) [i486-linux]

    Hmm... I just got a dejavu. Maybe I came across this before.

    T.
    Trans, Jun 19, 2007
    #1
    1. Advertising

  2. Trans

    Trans Guest

    On Jun 18, 10:35 pm, Yukihiro Matsumoto <> wrote:
    > Hi,
    >
    > It's not a bug. Assignments makes identifiers local variables,
    > statically.
    >
    > matz.


    This must be the matz-bot. The answer came instantaneously and, deja-
    vu again, I think it's same one I got before ;)

    Thanks matz,
    T.
    Trans, Jun 19, 2007
    #2
    1. Advertising

  3. Trans

    Robert Dober Guest

    On 6/19/07, Trans <> wrote:
    >
    >
    > On Jun 18, 10:35 pm, Yukihiro Matsumoto <> wrote:
    > > Hi,
    > >
    > > It's not a bug. Assignments makes identifiers local variables,
    > > statically.
    > >
    > > matz.

    >
    > This must be the matz-bot. The answer came instantaneously and, deja-
    > vu again, I think it's same one I got before ;)

    Let us see?

    Which assignment Matz?

    irb(main):001:0> def x;1 end
    => nil
    irb(main):002:0> if false then
    irb(main):003:1* def x; 2 end
    irb(main):004:1> end
    => nil
    irb(main):005:0> x
    => 1
    irb(main):006:0> def y; 1 end
    => nil
    irb(main):007:0> if false
    irb(main):008:1> undef y
    irb(main):009:1> end
    => nil
    irb(main):010:0> y
    => 1

    Surely the statements inside if are not executed.

    Cheers
    Robert
    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
    Robert Dober, Jun 19, 2007
    #3
  4. Trans

    Guest

    On 19 jun, 07:48, "Robert Dober" <> wrote:
    >
    > Let us see?
    >
    > Which assignment Matz?
    >
    > irb(main):001:0> def x;1 end
    > => nil
    > irb(main):002:0> if false then
    > irb(main):003:1* def x; 2 end
    > irb(main):004:1> end
    > => nil
    > irb(main):005:0> x
    > => 1
    > irb(main):006:0> def y; 1 end
    > => nil
    > irb(main):007:0> if false
    > irb(main):008:1> undef y
    > irb(main):009:1> end
    > => nil
    > irb(main):010:0> y
    > => 1
    >
    > Surely the statements inside if are not executed.
    >


    No, but they are parsed. And identifiers are made local variables at
    parse time, not at execution time. So if you have an assignment
    anywhere, even in a place that will never actually execute, the
    identifier used in the assignment will be considered a local variable
    by the interpreter.

    Christophe.
    , Jun 19, 2007
    #4
  5. Trans

    Robert Dober Guest

    On 6/19/07, <> wrote:

    >
    > No, but they are parsed. And identifiers are made local variables at
    > parse time, not at execution time. So if you have an assignment
    > anywhere, even in a place that will never actually execute, the
    > identifier used in the assignment will be considered a local variable
    > by the interpreter.
    >
    > Christophe.


    I guess this can be concluded by what is happening, but is this any
    reason to accept this behavior? I honestly do not feel so!

    Cheers
    Robert

    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
    Robert Dober, Jun 19, 2007
    #5
  6. Trans

    Trans Guest

    On Jun 19, 4:30 am, "Robert Dober" <> wrote:
    > On 6/19/07, <> wrote:
    >
    >
    >
    > > No, but they are parsed. And identifiers are made local variables at
    > > parse time, not at execution time. So if you have an assignment
    > > anywhere, even in a place that will never actually execute, the
    > > identifier used in the assignment will be considered a local variable
    > > by the interpreter.

    >
    > > Christophe.

    >
    > I guess this can be concluded by what is happening, but is this any
    > reason to accept this behavior? I honestly do not feel so!


    I do not feel so either. But, I've also learned that Ruby just has
    some quirks. Matz wouldn't had done it this way unless there was a
    very real need to do so. Now, that's not to say he might not have
    missed a better solution, so it's still worth discussing if anyone has
    one.

    T.
    Trans, Jun 19, 2007
    #6
  7. Trans

    Ian Whitlock Guest

    Trans wrote:

    >
    > Don't tell me, it's some quirk of the way Ruby works. Sure looks like
    > a bug though. Just in case:
    >
    > ruby 1.8.4 (2005-12-24) [i486-linux]
    >
    > Hmm... I just got a dejavu. Maybe I came across this before.
    >
    > T.


    T all you showed is that sometimes the programmer must be responsible
    for knowing whether he wants to reference a function or a variable.

    Consider:

    def x
    1
    end

    p x #recognize function call without parens

    if false
    x = x() + 1 #variable x is created when code parsed
    end

    p x #reference the variable x which is nil because no assignment was
    made
    p x() #if the above were the function, how would you reference the
    variable?

    Result:

    1
    nil
    1

    Ian

    --
    Posted via http://www.ruby-forum.com/.
    Ian Whitlock, Jun 19, 2007
    #7
  8. Trans

    Robert Dober Guest

    On 6/19/07, Ian Whitlock <> wrote:
    > Trans wrote:

    Tom it just strikes me, your thread and mine about Singleton classes
    not being in ancestors and small other things I always see the same
    pattern. Rick's blog entry is another example, always the same
    pattern, it is the pattern of imperfection which is the *only* thing
    that slightly bothers me in Ruby:


    Consistency.

    Maybe, probably I am wrong, but I feel that when it comes to these
    subtle things Ruby is lacking consistency.

    There just seems no reason for some behavior and your example above is
    a classical example. You ask yourself why and you cannot find an
    answer.

    And worst of all, you have to remember!!

    Still a great, great language of course.

    Robert

    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
    Robert Dober, Jun 19, 2007
    #8
  9. Trans

    Trans Guest

    On Jun 19, 4:02 pm, Ian Whitlock <> wrote:
    > Trans wrote:
    >
    > > Don't tell me, it's some quirk of the way Ruby works. Sure looks like
    > > a bug though. Just in case:

    >
    > > ruby 1.8.4 (2005-12-24) [i486-linux]

    >
    > > Hmm... I just got a dejavu. Maybe I came across this before.

    >
    > > T.

    >
    > T all you showed is that sometimes the programmer must be responsible
    > for knowing whether he wants to reference a function or a variable.


    One of things I always liked about Ruby is the fact the local vars and
    methods are, in a certain sens of the word, polymorphic. Where a
    method is being called, I can easily change it to be a variable. I
    don't have to go thru the code and remove ()s or vice versa.

    def chip
    "%s chip"
    end

    def good
    chip = "forget the %s chip"
    puts chip % "good"
    end

    So if you can do that, it would seem reasonable that one could do so
    conditionally as well. I find it odd that x is being setup as a local
    var before ever being assigned as such. That's quite declarative for a
    language that tends to shuns such things.

    T.
    Trans, Jun 19, 2007
    #9
  10. Trans

    Trans Guest

    On Jun 19, 4:27 pm, "Robert Dober" <> wrote:
    > On 6/19/07, Ian Whitlock <> wrote:> Trans wrote:
    >
    > Tom it just strikes me, your thread and mine about Singleton classes
    > not being in ancestors and small other things I always see the same
    > pattern. Rick's blog entry is another example, always the same
    > pattern, it is the pattern of imperfection which is the *only* thing
    > that slightly bothers me in Ruby:
    >
    > Consistency.
    >
    > Maybe, probably I am wrong, but I feel that when it comes to these
    > subtle things Ruby is lacking consistency.
    >
    > There just seems no reason for some behavior and your example above is
    > a classical example. You ask yourself why and you cannot find an
    > answer.
    >
    > And worst of all, you have to remember!!
    >
    > Still a great, great language of course.


    That is true. Ruby does have some rough edges. Though I chalk much of
    it up to the fact that convenience and flexibility often comes with a
    price of a few quirks.

    T.
    Trans, Jun 19, 2007
    #10
  11. "Robert Dober" <> writes:

    > I guess this can be concluded by what is happening, but is this any
    > reason to accept this behavior? I honestly do not feel so!


    On the other hand, I find the idea that the scoping and binding of
    variables could change based on the particular code path followed at
    run time a horribly non-intuitive concept, since I think of "variable
    scope" as something as static as the code itself - that is, you should
    only be able to screw with variable scoping by strange
    meta-programming tricks.

    --
    s=%q( Daniel Martin --
    puts "s=%q(#{s})",s.to_a.last )
    puts "s=%q(#{s})",s.to_a.last
    Daniel Martin, Jun 19, 2007
    #11
  12. --rwEMma7ioTxnRzrJ
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    On 2007-06-20 07:37:14 +0900 (Wed, Jun), Daniel Martin wrote:
    > On the other hand, I find the idea that the scoping and binding of
    > variables could change based on the particular code path followed at
    > run time a horribly non-intuitive concept, since I think of "variable
    > scope" as something as static as the code itself - that is, you should
    > only be able to screw with variable scoping by strange
    > meta-programming tricks.


    Maybe I don't understand something, but the decision whether something
    is a variable or is a method call is based not on the code executed
    (which is hard to predict when reading the source) but on the code
    parsed, which is pretty static.

    def this_method( x )
    p y # This 'y' will always be a method call.
    # (even if you call this_method again)
    if x
    y =3D 1 # because of this line in the source code...
    end
    p y # ...this 'y' will always be a variable.
    end # ..independent on the value of x

    So, I would (IMHO) assume, that this is not bad-black-magic, but
    good-and-understandable-white-magic aspect of ruby.

    The confision may emerge when the block of code has many lines, hard to
    grasp in one eye shot, but I have been taught that if you write a
    function that is longer than half of your editor window you should
    extract part of it into another function.
    With short blocks it is harder to mistake a method for a variable.

    P.S.:
    If someone still does not like this magic behaviour, assume that it
    saves you from writing:

    def this_method( x )
    p y
    if x
    #pragma set_as_variable(y) /* and if you forgot, you will get parse-error */
    y =3D 1
    end
    p y
    end

    ;-)

    --=20
    No virus found in this outgoing message.
    Checked by 'grep -i virus $MESSAGE'
    Trust me.

    --rwEMma7ioTxnRzrJ
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)

    iD8DBQFGeSxrsnU0scoWZKARAgWGAKDHXJoSBXQiY6Bsv5GGsDaUjCf/BQCfUCd5
    9stzUpzthKhT6KlcNcUxfVQ=
    =xe2b
    -----END PGP SIGNATURE-----

    --rwEMma7ioTxnRzrJ--
    Mariusz Pękala, Jun 20, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SteveLB
    Replies:
    0
    Views:
    325
    SteveLB
    Aug 8, 2003
  2. Collin VanDyck

    Comments get clobbered in transformation

    Collin VanDyck, Oct 15, 2003, in forum: Java
    Replies:
    1
    Views:
    337
    Patrick TJ McPhee
    Oct 15, 2003
  3. Collin VanDyck
    Replies:
    2
    Views:
    346
    Collin VanDyck
    Oct 15, 2003
  4. ChollaPete
    Replies:
    1
    Views:
    295
    ChollaPete
    Jun 28, 2009
  5. Richard Trahan

    node object gets clobbered after clone

    Richard Trahan, Sep 5, 2004, in forum: Javascript
    Replies:
    1
    Views:
    102
    Lasse Reichstein Nielsen
    Sep 5, 2004
Loading...

Share This Page