Professional Web Applications Themes

Inconsistent value of uninitialized variable - Ruby

The following statement, free of all context, generates an error: x # NameError: undefined local variable or method `x' ... So does this one: x = y # NameError: undefined local variable or method `y' ... However, this one does not (again, free of all context): x = x x # nil This, to me, is inconsistent and undesirable behaviour. I would prefer this: x = x # NameError: undefined local variable or method `x' ... I haven't given it much thought, but the existing behaviour cost me 15 minutes debugging, and I: * don't see a benefit of the ...

  1. #1

    Default Inconsistent value of uninitialized variable

    The following statement, free of all context, generates an error:

    x # NameError: undefined local variable or method `x' ...

    So does this one:

    x = y # NameError: undefined local variable or method `y' ...

    However, this one does not (again, free of all context):

    x = x
    x # nil

    This, to me, is inconsistent and undesirable behaviour. I would
    prefer this:

    x = x # NameError: undefined local variable or method `x' ...

    I haven't given it much thought, but the existing behaviour cost me 15
    minutes debugging, and I:
    * don't see a benefit of the existing behaviour;
    * do see a benefit (consistency) of changing the behaviour.

    Any comments?

    Gavin



    Gavin Guest

  2. #2

    Default Re: Inconsistent value of uninitialized variable

    Hi,

    In message "Inconsistent value of uninitialized variable"
    on 03/12/29, Gavin Sinclair <com.au> writes:

    |However, this one does not (again, free of all context):
    |
    | x = x
    | x # nil
    |
    |This, to me, is inconsistent and undesirable behaviour. I would
    |prefer this:
    |
    | x = x # NameError: undefined local variable or method `x' ...
    |
    |I haven't given it much thought, but the existing behaviour cost me 15
    |minutes debugging, and I:
    | * don't see a benefit of the existing behaviour;
    | * do see a benefit (consistency) of changing the behaviour.
    |
    |Any comments?

    It's just application of the simple rule "local variables are defined
    when they first appear in the left side of assignment", and was much
    easier to implement.

    I wouldn't disagree with you (but not really motivated enough to fix
    by myself).

    matz.

    Yukihiro Guest

  3. #3

    Default Re: Inconsistent value of uninitialized variable

    On Dec 28, 2003, at 09:04, Gavin Sinclair wrote:
     

    Isn't it this behavior that makes it possible to define a recursive
    block?

    y = 0
    x = proc{y += 1; x.call unless(y == 100); y}
    p x.call

    I suppose you could require a prior assignment to x in this case, but
    that starts to smell like having to declare variables...

    Just my $0.02,


    Nathaniel

    <:((><



    Nathaniel Guest

  4. #4

    Default Re: Inconsistent value of uninitialized variable

    On Mon, 29 Dec 2003 00:04:19 +0900, Gavin Sinclair
    <com.au> wrote:
    [snip] 


    Just recently there was a discussion on using procs that referenced
    methods not yet defined:

    even = proc{|x| x == 0 ? true : odd[x-1]}
    odd = proc{|x| x == 0 ? false : even[x-1]}
    p even[5]

    and we get an error because 'odd' is undefined when 'even' was defined.
    One way around this is to simply set 'odd' to nil first:

    odd = nil
    even = proc{|x| x == 0 ? true : odd[x-1]}
    odd = proc{|x| x == 0 ? false : even[x-1]}
    p even[5]

    But, as a result of current behavior, the extra nil assignment can be
    avoided via:

    even, odd = proc {|x| x == 0 ? true : odd[x-1]},
    proc {|x| x == 0 ? false : even[x-1]}
    p even[5]

    I'm sure opinions will vary greatly on whether this is a benefit :-)

    regards,
    andrew

    Andrew Guest

  5. #5

    Default Re: Inconsistent value of uninitialized variable

    Gavin Sinclair <com.au> writes: 

    I had a similar problem a while ago that also took time to debug.
    I had code looking something like this:

    x_misspelled = 33
    ...
    x = 100 if x == -1

    Because of the rule Matz referred to in his reply to your mail (that
    "local variables are defined when they first appear in the left side
    of assignment"), this code doesn't give an error. If I had written

    x_misspelled = 33
    ...
    if x == -1
    x = 100
    end

    I would have got a NameError saying "undefined local variable
    or method...".

    I think these two code fragments does the same thing "logically", and
    that it would have been nice if the if-modifier-form also had caught
    my error.

    /Johan Holmberg

    Johan Guest

  6. #6

    Default Re: Inconsistent value of uninitialized variable

    On Monday, December 29, 2003, 4:29:45 AM, Nathaniel wrote:
     
     [/ref]
     
     

    I don't believe so, because the 'x' in question above is not being
    assigned; 'x.call' is semantically equivalent to 'x' (an rvalue), not
    'x = something' (an lvalue).

    What makes the above code possible is that 'x' in 'x.call' is not
    evaluated until it is actually run; there's no compiler to please.

    Gavin




    Gavin Guest

  7. #7

    Default Re: Inconsistent value of uninitialized variable

    Nathaniel Talbott <ws> wrote: 

    This is not a proper recursive block - for instance

    y = 0
    x = proc{y += 1; x.call unless(y == 100); y}
    z = x
    x = nil
    z.call

    martin
    Martin Guest

  8. #8

    Default Re: Inconsistent value of uninitialized variable

    On Dec 28, 2003, at 23:11, Martin DeMello wrote:
     
    >
    > This is not a proper recursive block - for instance
    >
    > y = 0
    > x = proc{y += 1; x.call unless(y == 100); y}
    > z = x
    > x = nil
    > z.call[/ref]

    "Not proper" might be strong language, but yes, it could definitely be
    broken. Do you have a better construct for a recursive block?


    Nathaniel

    <:((><



    Nathaniel Guest

  9. #9

    Default Re: Inconsistent value of uninitialized variable

    On Mon, Dec 29, 2003 at 02:34:40PM +0900, Nathaniel Talbott wrote: 
    > >
    > >This is not a proper recursive block - for instance
    > >
    > >y = 0
    > >x = proc{y += 1; x.call unless(y == 100); y}
    > >z = x
    > >x = nil
    > >z.call[/ref]
    >
    > "Not proper" might be strong language, but yes, it could definitely be
    > broken. Do you have a better construct for a recursive block?[/ref]
     [/ref]
    => #<Proc:0x401af0f0(irb):3> [/ref]
    => nil [/ref]
    => 100

    With the new block local rules,
    y = 0; z = proc{|*z| z = proc{y += 1; z.call unless y == 100}; z.call }
    a = z
    z = nil
    a.call

    would work too (you'd get a warning IIRC, though).

    If you're "evil" enough you might like the following too:

    y = 0

    proc {|l| proc{|f| f.call(f)}.call(proc{|f|
    l.call(proc{|*x| f.call(f).call(x)})})
    }.call(proc {|r| proc{y += 1; r.call unless y == 100}}).call

    ;)

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    I tried the clone syscall on me, but it didn't work.
    -- Mike Neuffer trying to fix a serious time problem


    Mauricio Guest

  10. #10

    Default Re: Inconsistent value of uninitialized variable

    Nathaniel Talbott <ws> wrote: 
    > >
    > > This is not a proper recursive block - for instance
    > >
    > > y = 0
    > > x = proc{y += 1; x.call unless(y == 100); y}
    > > z = x
    > > x = nil
    > > z.call[/ref]
    >
    > "Not proper" might be strong language, but yes, it could definitely be[/ref]

    Sorry. Actually, you're right - this'll cover nearly every case in which
    you'd want the construct, but relying on a variable name makes me
    twitchy.
     

    No, I remember fighting over it once, but I didn't get anywhere. I'd
    like to see some equivalent to letrec in 2.0, personally.

    martin
    Martin Guest

Similar Threads

  1. Replies: 0
    Last Post: October 13th, 11:18 PM
  2. Replies: 0
    Last Post: October 13th, 11:18 PM
  3. Replies: 0
    Last Post: October 13th, 11:17 PM
  4. #25856 [NEW]: Segfault when copying uninitialized variable into array sub-index
    By cluby at omniture dot com in forum PHP Development
    Replies: 0
    Last Post: October 13th, 07:47 PM
  5. #22836 [Ver->Csd]: returning reference to uninitialized variable
    By iliaa@php.net in forum PHP Development
    Replies: 0
    Last Post: July 29th, 05:57 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139