From: Adam Prescott <mentionuse@...>
Date: 2011-01-24T23:43:20+09:00
Subject: Re: The finer points of postfix conditionals.

--0016364c7d71e345b6049a989ea4
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 24, 2011 at 2:22 PM, Jon Leighton <j@jonathanleighton.com>wrote:

> Also consider:
>
> foo = 1
> foo = 2 if false
>
> This results in foo keeping its value of 1, not being assigned to nil.
> So it is not simply the case that the second statement is parsed as:
>

Not being assigned to nil here makes sense, even without knowing why it gets
assigned to nil in your other examples; the interpreter wouldn't want to
override an existing value of foo.

I can't answer the other questions as I don't know enough about how the
interpreter is handling the source code, however I would guess that the
existence of an assignment in the source code causes the "foo" local
variable to be added as existent within its scope, even though an assignment
has not actually occurred.

I can see this causing problems in certain cases, perhaps if, somewhere in
the code, there was something like:

if foo
  ...     #  (1)
end

which was somehow after an assignment like

... if foo = some_value  #  (2)

If (2) were removed, (1) would cause an error. But I can't see this being
likely at all.

I'd be interested to know the answer to your question. I suspect parse_tree
will be useful here.

Related to this:

x # NameError
x = x # => nil
x # => nil

--0016364c7d71e345b6049a989ea4--