do not understand this closure

D

Dave Rose

in The Ruby Way...chap 1...a crude example of closure doesn't work as
this irb
session:NoMethodError: undefined method `square' for main:Object
from (irb):7NoMethodError: undefined method `square' for main:Object
from (irb):8SyntaxError: compile error
(irb):10: syntax error
from (irb):10NoMethodError: undefined method `square' for main:Object
..futhermore...where (if it's implied...) is base come into play
here....
 
M

Martin DeMello

in The Ruby Way...chap 1...a crude example of closure doesn't work as
this irb
session:
NoMethodError: undefined method `square' for main:Object
from (irb):7

You want square[11] or square.call(11)

square(11) is interpreted as "call the method 'square' on the current
"self" object, with the argument '11'", whereas square[11] is
interpreted as "call the method [] on the object 'square' with the
argument 11. Proc defines [] to be a synonym of call.

martin
 
M

Martin DeMello

Is there any way to have a proc object be callable identically to a method,
ie with the parentheses? Is there a reason to keep the notation distinct?

No, mostly because () is not a method, it's syntax. [] on the other
hand is a method, and therefore available for Proc#[] to be aliased to
Proc#call

martin
 
A

ara.t.howard

Is there any way to have a proc object be callable identically to a method,
ie with the parentheses? Is there a reason to keep the notation distinct?

Thanks,
-rr-

harp:~ > cat a.rb
def the_method() 'namespace one' end

the_method = String.new 'namespace two'

p the_method()
p the_method


harp:~ > ruby a.rb
"namespace one"
"namespace two"

that said, 1.9 has support for a_proc()

-a
 
D

Dave Rose

Martin said:
Is there any way to have a proc object be callable identically to a method,
ie with the parentheses? Is there a reason to keep the notation distinct?

No, mostly because () is not a method, it's syntax. [] on the other
hand is a method, and therefore available for Proc#[] to be aliased to
Proc#call

martin

oka...please explain for me where |base| parameter is comming
from...irb:
[4]power(5)
yntaxError: compile error
irb):9: syntax error
4]power(5)
^
from (irb):9
yntaxError: compile error
irb):10: syntax error
from (irb):10
4.power(5)
#<Proc:0x02dc58f0@(irb):2>
power(5).4
yntaxError: compile error
irb):12: no .<digit> floating literal anymore; put 0 before dot
ower(5).4
^
irb):12: syntax error
from (irb):12
power(4)[4]
256
power(4)0.4
yntaxError: compile error
irb):14: syntax error
from (irb):14
power(5)[4]
1024
 
M

Mauricio Fernandez

harp:~ > cat a.rb
def the_method() 'namespace one' end

the_method = String.new 'namespace two'

p the_method()
p the_method


harp:~ > ruby a.rb
"namespace one"
"namespace two"

that said, 1.9 has support for a_proc()

This used to work:

$ cat proc.rb
a = proc{|x| p x}
(a)(1)

... but doesn't anymore.

$ ruby19 -v proc.rb
ruby 1.9.0 (2006-08-13) [i686-linux]
proc.rb:2: warning: useless use of a variable in void context
proc.rb:2: syntax error, unexpected '(', expecting $end
(a)(1)


Right now, it's

RUBY_RELEASE_DATE # => "2006-08-13"
RUBY_VERSION # => "1.9.0"
a = proc{|x| x+1}
a.(2) # => 3


[gotta update my changelog]
 
A

ara.t.howard

that said, 1.9 has support for a_proc()

This used to work:

$ cat proc.rb
a = proc{|x| p x}
(a)(1)

... but doesn't anymore.

$ ruby19 -v proc.rb
ruby 1.9.0 (2006-08-13) [i686-linux]
proc.rb:2: warning: useless use of a variable in void context
proc.rb:2: syntax error, unexpected '(', expecting $end
(a)(1)


Right now, it's

RUBY_RELEASE_DATE # => "2006-08-13"
RUBY_VERSION # => "1.9.0"
a = proc{|x| x+1}
a.(2) # => 3

huh. so '()' is a method name now?

-a
 
M

Mauricio Fernandez

that said, 1.9 has support for a_proc()
[...]
Right now, it's

RUBY_RELEASE_DATE # => "2006-08-13"
RUBY_VERSION # => "1.9.0"
a = proc{|x| x+1}
a.(2) # => 3

huh. so '()' is a method name now?

nope, it's just sugar standing for #call:

RUBY_VERSION # => "1.9.0"
RUBY_RELEASE_DATE # => "2006-08-13"
a = Object.new
def a.call(x); x+1 end
a.(2) # => 3
 
A

ara.t.howard

nope, it's just sugar standing for #call:

RUBY_VERSION # => "1.9.0"
RUBY_RELEASE_DATE # => "2006-08-13"
a = Object.new
def a.call(x); x+1 end
a.(2) # => 3

hmmm. seems pointless. unless i can do

a_method_or_proc(arg)

it one more chare than

a_proc[arg]

a_method[arg]

oh well, thanks for the info!

-a
 
H

Hal Fulton

rak said:
Is there any way to have a proc object be callable identically to a method,
ie with the parentheses? Is there a reason to keep the notation distinct?

I think it's difficult. Ruby distinguishes between method names
and variable names by how they are used. In this case, you'd be
using the same name both ways.


Hal
 
H

Hal Fulton

rak said:
Perhaps this could be an rcr? I'm having trouble seeing why Ruby would
impose a syntactic difference between a proc and a method call. It
would be
nice syntactic sugar IMO.

I just tried to explain why. A proc is stored in a variable.
A variable can't have () after it, because it will look like
a method call.

It's *conceivable* this could be changed, but then people would
(accidentally or on purpose) try to "call" a variable that
didn't refer to a proc:

a = 5
a()

Then Ruby would have to be smart enough to call the method a
rather than trying to call the proc that isn't referred to
by a.

Furthermore, suppose you have both. Which takes precedence?

def say
puts "hello"
end

say = proc { puts "goodbye" }

say() # hello or goodbye?



Cheers,
Hal
 
D

dblack

Hi --

This would fail just like a.call() would fail.

def say


I would say this would be similar to redefining a method, where the latest
definition takes precedence.

That's never going to work. It would quickly become a nightmare of
scoping and naming issues.

Methods and Procs just aren't at the same level of indirection from
their written identifiers. It's better to keep that difference
visible.


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.
 
M

Matthew Johnson

That's never going to work. It would quickly become a nightmare of
scoping and naming issues.

Methods and Procs just aren't at the same level of indirection from
their written identifiers. It's better to keep that difference
visible.

There are languages (Scheme is one if I remember correctly) where the
two are semantically equivalent and thus () is used as a call
operator for both types of definitions. All functions / methods are
anonymous unless bound to a name. In such a language this would
indeed be a redefinition of the method as def is simply syntactic
sugar. This is approach is clean and simple in many respects, but is
different than the approach Ruby takes. Unless Ruby were to change
its semantics (not likely) I think David is right that this approach
won't work in Ruby.

Matthew
 
C

Chad Perrin

There are languages (Scheme is one if I remember correctly) where the
two are semantically equivalent and thus () is used as a call
operator for both types of definitions. All functions / methods are
anonymous unless bound to a name. In such a language this would
indeed be a redefinition of the method as def is simply syntactic
sugar. This is approach is clean and simple in many respects, but is
different than the approach Ruby takes. Unless Ruby were to change
its semantics (not likely) I think David is right that this approach
won't work in Ruby.

. . except that in Lisps the () is list syntax, and the reason
closures and methods share that syntax is that everything is a list.
That's my understanding, anyway. Then again, I'm no Lisp expert.

On the other hand, Perl might be a good example of unified syntax for
methods and closures. In both cases, calling the thing involves a
dereferencing, for which ->() is the syntax.
 
M

Martin DeMello

This would fail just like a.call() would fail.

def say


I would say this would be similar to redefining a method, where the latest
definition takes precedence.

Read up on the difference between a lisp 1 and a lisp 2. (Which is not
intended to be condescending or dismissive; just that reams have been
written on the topic and I see no point in rehashing it imperfectly in
here.) Essentially it boils down to whether functions and variables
share a namespace or not.

martin
 
M

Matthew Johnson

. . . except that in Lisps the () is list syntax, and the reason
closures and methods share that syntax is that everything is a list.
That's my understanding, anyway. Then again, I'm no Lisp expert.

On the other hand, Perl might be a good example of unified syntax for
methods and closures. In both cases, calling the thing involves a
dereferencing, for which ->() is the syntax.

True, I was thinking of invocation and typed () where that doesn't
apply to Lisp. The point was that in some languages invocation is
accomplished in the same way since the two forms of definition are
semantically equivalent. If I remember correctly (it has been quite
a while since I've looked at Lisp and Scheme) this is actually a
difference between Scheme and Lisp. Scheme has a single namespace
for variable definitions and function definitions whereas in Common
Lisp the two are separate. I actually much prefer the Scheme
approach and consider it to be more beautiful and simple. The
biggest barrier to something like this in Ruby (at least in 1.8.x) is
that the parameters are handled slightly differently for the two (ex.
procs cannot take a block).

Matthew
 
C

Chad Perrin

True, I was thinking of invocation and typed () where that doesn't
apply to Lisp. The point was that in some languages invocation is
accomplished in the same way since the two forms of definition are
semantically equivalent. If I remember correctly (it has been quite
a while since I've looked at Lisp and Scheme) this is actually a
difference between Scheme and Lisp. Scheme has a single namespace
for variable definitions and function definitions whereas in Common
Lisp the two are separate. I actually much prefer the Scheme
approach and consider it to be more beautiful and simple. The
biggest barrier to something like this in Ruby (at least in 1.8.x) is
that the parameters are handled slightly differently for the two (ex.
procs cannot take a block).

I wasn't aware of that -- it seems like a pretty severe (if rarely
imposing) limitation. At first glance, it also looks like a largely
arbitrary limitation, though I'm pretty sure there are at least
implementation issues involved, since last I checked the Ruby community
doesn't seem to suffer from Guidoism (aka: lambdas are one line of code,
period, because I say so, also period).
 
M

Matthew Johnson

I wasn't aware of that -- it seems like a pretty severe (if rarely
imposing) limitation. At first glance, it also looks like a largely
arbitrary limitation, though I'm pretty sure there are at least
implementation issues involved, since last I checked the Ruby
community
doesn't seem to suffer from Guidoism (aka: lambdas are one line of
code,
period, because I say so, also period).

This has been changed in Ruby 1.9 so it seems to open the possibility
of changing things in the future (to a unified method and variable
namespace), although I would be surprised if such a change were to
happen.

Matthew
 
G

Gustav - Railist

Hey

I can't seem to get this simple DRb client to access the server over my
network...
I get a bad file descriptor error.
############# The Client Script ################
require 'drb'
DRb.start_service
server = DRbObject.new(nil, "druby://#{ARGV.shift}")
my_id = server.initialize_me
puts my_id


############# The Server Script ###############
require 'drb'
class PerformAlexaUpdate
def initialize_me
return 'hello'
end
end
h_server = DRb::DRbServer.new 'druby://127.0.0.1:5555',
PerformAlexaUpdate.new
h_server.thread.join
###########################################

Any ideas will be greatly appreciated!

Thanks in advance,
Gustav
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Staff online

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top