# Unification of variables and methods

**URL:** <https://www.ruby-forum.com/t/unification-of-variables-and-methods/85886>\
**Category:** Ruby\
**Created:** [February 17, 2007, 6:16am UTC](https://www.ruby-forum.com/t/unification-of-variables-and-methods/85886 "2007-02-17T06:16:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![calande](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/edb3f5/32.png) [@calande](https://www.ruby-forum.com/u/calande)\
**Post date:** [February 17, 2007, 6:16am UTC](https://www.ruby-forum.com/t/unification-of-variables-and-methods/85886/1 "2007-02-17T06:16:21Z")

</div>

The one thing that bothers me about ruby is the (as i see it?) separate  
namespaces for locals and functions.

Variables take precedence, but you can override and get the functional  
form in 2 ways:

def x; 1; end  
x = 2  
x # =\> 2  
x() # =\> 1  
self.x # =\> 1

1. It seems somewhat messy, and prohibits using () as a message (eg,  
sending :call)

x = proc { 1 }  
x() # NoMethodError…  
x[] # =\> 1

2a. It also leads to a more complex language to parse, and to those  
interesting issues like:

def x; 1; end  
x # =\> 1  
x = 2 if false  
x # =\> nil

2b. And other confusion as `\*’, ‘&’ and ‘/’ being mistaken at times,  
with certain whitespace dependencies:

def foo1; end  
foo2 = ‘’

foo1 / 1 # this / is division  
foo1 /1 # this / starts an (as-yet unterminated) regexp.  
foo2 / 1 # this / is division also  
foo2 /1 # this / is also division! yet actually IRB trips up, looks  
# for the rest of /, then gives a SyntaxError on  
compilation.

a = [1, 2]  
foo1 \* a # \* means splat  
foo2 \* b # \* means multiply

I don’t understand why they both just can’t get along? 🙂  
(ie at least in the same namespace, optionally with parsing not  
dependent on the guessed type).

---

<div class="post-metadata">

**Author:** ![calande](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/edb3f5/32.png) [@calande](https://www.ruby-forum.com/u/calande)\
**Post date:** [February 17, 2007, 7:02am UTC](https://www.ruby-forum.com/t/unification-of-variables-and-methods/85886/2 "2007-02-17T07:02:49Z")

</div>

Hi,

In message “Re: Unification of variables and methods”  
on Sat, 17 Feb 2007 14:16:24 +0900, Charles L.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:

|The one thing that bothers me about ruby is the (as i see it?) separate  
|namespaces for locals and functions.

I think unification makes

obj.foo

to retrieve foo method object a la Python, which I believe is not the  
best way for programmers. In short, I took CommonLisp way over  
Scheme way.

Some points you have pointed are negotiable.

```
          matz.

```

---

<div class="post-metadata">

**Author:** ![calande](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/edb3f5/32.png) [@calande](https://www.ruby-forum.com/u/calande)\
**Post date:** [February 23, 2007, 7:41am UTC](https://www.ruby-forum.com/t/unification-of-variables-and-methods/85886/3 "2007-02-23T07:41:10Z")

</div>

Yukihiro M. wrote:

> Hi,
> 
> In message “Re: Unification of variables and methods”  
> on Sat, 17 Feb 2007 14:16:24 +0900, Charles L.  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:
> 
> |The one thing that bothers me about ruby is the (as i see it?) separate  
> |namespaces for locals and functions.
> 
> I think unification makes
> 
> obj.foo
> 
> to retrieve foo method object a la Python, which I believe is not the  
> best way for programmers. In short, I took CommonLisp way over  
> Scheme way.
> 
> Some points you have pointed are negotiable.
> 
> ```
> matz.
> 
> ```

Thanks for the response. In some ways i suppose, I’ve always found  
scheme somehow more elegant that commonlisp, so perhaps we are looking  
for different things…

I think though, that unification of vars/methods, and whether a bare  
method name should auto-apply (as it were) are orthogonal? And I  
certainly don’t advocate the removal of the latter (ie obj.foo returning  
a method object). That is part of what gives ruby its beauty IMO.  
A unified namespace does pave the way for () to map to #call (although  
such semantics aren’t required), and it doesn’t preclude the use of  
plain methods.  
Rather consider something like this:

def foo  
…  
end

bar = proc { … }

foo # calls a method  
foo() # also calls a method  
method(:foo) # gets method object (proc)  
bar # gets a proc  
bar() # calls that proc

Its merely a syntactic sugar i guess, but in a way, you then have the  
option of doing things python style, which is not my intention, and  
possibly undesirable.

I think that the semantics are neater in the before mentioned case of  
collisions:

def x; 1; end  
x = 2  
x # =\> 2  
x() # =\> 1

If that final one were to either try to #call the x variable, or throw a  
runtime error, or something, it would be (IMO of course) better.

In order to try to fake it for local variables, i tried this hack  
once-upon-a-time:

def method\_missing(sym, \*args, &block)  
sym = sym.to\_s  
error = NameError.new “undefined local variable or method `#{sym}'”  
Binding.of\_caller do |binding|  
raise error unless eval(‘local\_variables’, binding).include?  
sym.to\_s  
func = eval(sym, binding)  
raise error unless func.respond\_to? :call  
func.call(\*args, &block)  
end  
end

At any rate, just glad you’ve considered it - Ruby is great, so I trust  
your judgement 🙂