Local variables, blocks & self ambiguity (was Local variables & blocks)

ruby-talk
1

eeee.....well, they wouldn't be local then :slight_smile: on the other hand is self became
associated to the def, then other problems would arise. okay, so that was
actually a dumb idea. :0o

There's another thing. Presumably you would like to resolve the "local
variable versus attribute writer" ambiguity:

    leftvol = rightvol = 0 # local variable assignments
    self.leftvol = self.rightvol = 0 # method calls leftvol=, rightvol=

Actually, this could be solved in the current scenario, simply by searching
for a 'leftvol=' method before falling back to a local variable assignment.

The efficiency cost, however, would be unbearable. Imagine the simple
statement:

    x = 0

which at the moment, can be infered (at compile time) to be an assignment to
a local variable. If this could not be assumed to be a local variable, then
a complete method search would have to be done (at run time) every time this
statement is executed - all the way up the class hierarchy. Methods can be
added dynamically to an object at any time, so there's no way to cache this
information.

Furthermore, consider cases like this:

    if ... some condition
       ...
       flag = true
    end

    flag && do_something

In the current model, 'flag' is always available at the final statement, as
a known local variable, with value 'nil' if not assigned. If it were
dynamically created, then the final statement might crash altogether. If
there were any chance of this happening, you would have to add 'flag=nil' at
the top of the code, effectively a declaration of the variable.

You could of course resolve this by making local variables have a distinct
syntax from method calls - say $variable. Oops, we wouldn't want that :slight_smile:

Cheers,

Brian.

2

Actually, this could be solved in the current scenario, simply by searching
for a ‘leftvol=’ method before falling back to a local variable assignment.

The efficiency cost, however, would be unbearable. Imagine the simple
statement:

x = 0

and also a much more subtle problem arises involving inheritence. so subtle in
fact i can’t recall how it actually occurs, but it was point out by david
balck i think some time ago. this fallback idea just dosen’t work either,
despite how slow it might be.

Furthermore, consider cases like this:

if ... some condition
   ...
   flag = true
end

flag && do_something

In the current model, ‘flag’ is always available at the final statement, as
a known local variable, with value ‘nil’ if not assigned. If it were
dynamically created, then the final statement might crash altogether. If
there were any chance of this happening, you would have to add ‘flag=nil’
at the top of the code, effectively a declaration of the variable.

another good point.

You could of course resolve this by making local variables have a distinct
syntax from method calls - say $variable. Oops, we wouldn’t want that :slight_smile:

:slight_smile: yes, sometimes i think it would just have been better if local variables
were prefixed with say, %x = 1.

my idea of scope.x = 1 dosen’t help this ambiguity either really.

hmmm… you know what. here’s the thing. it really is all about scope. $
specifies a global scope, @ an object scope (@@ the class scope), and no
prefix means the local scope. that’s for variables. but for methods it’s
different. what would a global method be?, “ClassName.” is the prefix used
for class methods, and no prefix means object scoped methods (a shortcut for
‘self.’) …no prefix the source of the ambiguity.

by contrast we certainly don’t do around calling $bar() or @bar() or @@bar()
as method calls. nor do we use ClassName.x or self.x to mean a class
variable.

so here’s a chart:

	variable		method

global $ (what?)
class @@ ClassName.
object @ self. (or none)
local (none) (n/a)

so i guess i just like to wonder if there could be a better chart.

¡¡¡

On Saturday 01 February 2003 07:09 am, Brian Candler wrote:

–
tom sawyer, aka transami
transami@transami.net

3

Furthermore, consider cases like this:

if … some condition
…
flag = true
end

flag && do_something

In the current model, ‘flag’ is always available at the final statement, as
a known local variable, with value ‘nil’ if not assigned. If it were
dynamically created, then the final statement might crash altogether. If
there were any chance of this happening, you would have to add ‘flag=nil’ at
the top of the code, effectively a declaration of the variable.

I don’t think the proposed change alters this behaviour at all.

Consider this too:

def condn(test)
yield if test
end

condn(test) {
…
flag = true
}

p flag # => undefined local variable or method (NameError)

Whereas with the proposed modification blocks would behave more like
built-in constructs like ‘if’ and ‘case’.

martin

¡¡¡

Brian Candler B.Candler@pobox.com wrote:

You could of course resolve this by making local variables have a distinct
syntax from method calls - say $variable. Oops, we wouldn’t want that :slight_smile:

Cheers,

Brian.

4

I believe you’re talking about matz’s proposal :slight_smile:

¡¡¡

On Sun, Feb 02, 2003 at 12:09:27AM +0900, Martin DeMello wrote:

Brian Candler B.Candler@pobox.com wrote:
Furthermore, consider cases like this:

if … some condition
…
flag = true
end

flag && do_something

In the current model, ‘flag’ is always available at the final statement, as
a known local variable, with value ‘nil’ if not assigned. If it were
dynamically created, then the final statement might crash altogether. If
there were any chance of this happening, you would have to add ‘flag=nil’ at
the top of the code, effectively a declaration of the variable.

I don’t think the proposed change alters this behaviour at all.

Consider this too:

def condn(test)
yield if test
end

condn(test) {
…
flag = true
}

p flag # => undefined local variable or method (NameError)

Whereas with the proposed modification blocks would behave more like
built-in constructs like ‘if’ and ‘case’.

–
_ _

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

Computers are like air conditioners. Both stop working, if you open windows.
– Adam Heath

5

I believe you’re right :slight_smile:

martin

¡¡¡

Mauricio Fern?ndez batsman.geo@yahoo.com wrote:

I believe you’re talking about matz’s proposal :slight_smile: