Different semantics of Proc and method call -- bug or feature?

[Tammo Freese]

Hi all,


I stumbled over the following difference between method calls and
Proc calls:

require 'pp';

def a_method(arg, *args)
arg
end

a_proc = Proc.new do | arg, *args |
arg
end

pp a_method(1) # => expected 1, got 1
pp a_proc.call(1) # => expected 1, got 1

pp a_method([1]) # => expected [1], got [1]
pp a_proc.call([1]) # => expected [1], got 1 <== ?!


I would expect that method calls and proc calls do not differ in such
a way.
Is this a bug or a feature?


Thanks for your help,

Tammo

 

[Robert Klemme]

Hi all,


I stumbled over the following difference between method calls and Proc
calls:

require 'pp';

def a_method(arg, *args)
arg
end

a_proc = Proc.new do | arg, *args |
arg
end

pp a_method(1) # => expected 1, got 1
pp a_proc.call(1) # => expected 1, got 1

pp a_method([1]) # => expected [1], got [1]
pp a_proc.call([1]) # => expected [1], got 1 <== ?!


I would expect that method calls and proc calls do not differ in such a
way.
Is this a bug or a feature?

I think it's rather a feature although I can understand your surprise.
IIRC block (and thus proc) parameters behave more similar to assignments:

def t
yield 1
yield [2]
yield [3,4]
end => nil
t {|a| p a}

1
[2]
[3, 4]
=> nil1
2
3
=> nil1
2
3
=> nil

15:04:11 [~]: ruby -e 'a=1; p a; a=[2,3]; p a'
1
[2, 3]
15:04:45 [~]: ruby -e 'a=1; p a; a=[2]; p a; a=[3,4]; p a'
1
[2]
[3, 4]
15:05:08 [~]: ruby -e 'a,*b=1; p a; a,*b=[2]; p a; a,*b=[3,4]; p a'
1
2
3
15:05:25 [~]: ruby -e 'a,=1; p a; a,=[2]; p a; a,=[3,4]; p a'
1
2
3
15:05:34 [~]:

HTH

Kind regards

robert

 

[Morton Goldberg]

This _is_ strange. R. Klemme's explanation is enlightening, but now I
wonder why qq in the following works like a method definition rather
than like pp?

#! /usr/bin/ruby -w

pp = Proc.new do |arg, *args|
p [arg, args]
end

qq = lambda do |arg, *args|
p [arg, args]
end

s = 1
v = [2]

puts VERSION => 1.8.2

pp.call s => [1, []]
pp.call v => [2, []]
pp.call v, v => [[2], [[2]]]

qq.call s => [1, []]
qq.call v => [[2], []]
qq.call v, v => [[2], [[2]]]

Regards, Morton

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Different semantics of Proc and method call -- bug or feature?"

|I would expect that method calls and proc calls do not differ in such
|a way.
|Is this a bug or a feature?

It's a feature, but we are trying to fix it in the next major release
(1.9 or 2.0).

matz.

 

[James Edward Gray II]

It's a feature, but we are trying to fix it in the next major release
(1.9 or 2.0).

Matz, could you tell us why you are considering releasing the next
major version as 1.9 instead of 2.0?

James Edward Gray II

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Next Major Version (was Re: Different semantics of Proc and method call -- bug or feature?)"

|On Aug 2, 2006, at 9:05 AM, Yukihiro Matsumoto wrote:
|
|> It's a feature, but we are trying to fix it in the next major release
|> (1.9 or 2.0).
|
|Matz, could you tell us why you are considering releasing the next
|major version as 1.9 instead of 2.0?

In the current pace, it would take years to release 2.0, but some
requested features we already made in 1.9 branch. We felt the request
is reasonable.

matz.

 

[N Okia]

In keeping with your current numbering scheme, does this mean there
will be a ruby 1.10 release?

 

[Matt Todd]

What was it Mauricio had announced... Version 1.z or was it 1.Gamma
sometime in 2017?



M.T.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Next Major Version (was Re: Different semantics of Proc and method call -- bug or feature?)"

|In keeping with your current numbering scheme, does this mean there
|will be a ruby 1.10 release?

The version letters will be stay in one letter each, so that 1.a will
be more likely than 1.10.

matz.

 

[Rick DeNatale]

Hi,

In message "Re: Next Major Version (was Re: Different semantics of Proc and method call -- bug or feature?)"

|In keeping with your current numbering scheme, does this mean there
|will be a ruby 1.10 release?

The version letters will be stay in one letter each, so that 1.a will
be more likely than 1.10.

matz.

Matz,

I hesitate to ask YOU this, but are you really sure you want to go that way.

Almost every software package I've run across keeps each level of the
version "number" as a number, so 1.10 would be much more in line with
standard practice than 1.a

 

[James Edward Gray II]

Matz,

I hesitate to ask YOU this, but are you really sure you want to go
that way.

Almost every software package I've run across keeps each level of the
version "number" as a number, so 1.10 would be much more in line with
standard practice than 1.a

But it can't be compared properly using Ruby operators:
=> false

James Edward Gray II

 

[transfire]

But it can't be compared properly using Ruby operators:

=> false

Which is another good reason for Ruby to have an actual Tuple class.

T.

 

[Rick DeNatale]

On Aug 3, 2006, at 10:26 AM, Rick DeNatale wrote:


But it can't be compared properly using Ruby operators:

=> false

Ah, but doing the comparison correctly in Ruby isn't that hard, in a
few minutes I came up with:

irb(main):023:0> class Version
irb(main):024:1> include Comparable
irb(main):025:1>
irb(main):026:1* def initialize(string)
irb(main):027:2> @value = string.split('.').collect { | i | i.to_i }
irb(main):028:2> end
irb(main):029:1>
irb(main):030:1* def <=>(another)
irb(main):031:2> @value <=> another.to_ary
irb(main):032:2> end
irb(main):033:1>
irb(main):034:1* def to_ary
irb(main):035:2> @value
irb(main):036:2> end
irb(main):037:1> end
=> nil
irb(main):038:0> Version.new("1.8.5")
=> #<Version:0xb7d728e8 @value=[1, 8, 5]>
irb(main):039:0> Version.new("1.8.5") < Version.new("1.10.0")
=> true

I'd strongly suggest, that it's much better for Ruby if it tries to
stay in line as much as possible with how things are done in the open
source community.

There's a lot of software outside of Ruby which depends on having
versions being a tuple of numbers. Since Ruby makes it easy to meet
things like that more than halfway, I think that it's better to do so.

--
Rick DeNatale

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/

 

[ara.t.howard]

=> false

Ah, but doing the comparison correctly in Ruby isn't that hard, in a
few minutes I came up with:

irb(main):023:0> class Version
irb(main):024:1> include Comparable
irb(main):025:1>
irb(main):026:1* def initialize(string)
irb(main):027:2> @value = string.split('.').collect { | i | i.to_i }
irb(main):028:2> end
irb(main):029:1>
irb(main):030:1* def <=>(another)
irb(main):031:2> @value <=> another.to_ary
irb(main):032:2> end
irb(main):033:1>
irb(main):034:1* def to_ary
irb(main):035:2> @value
irb(main):036:2> end
irb(main):037:1> end
=> nil
irb(main):038:0> Version.new("1.8.5")
=> #<Version:0xb7d728e8 @value=[1, 8, 5]>
irb(main):039:0> Version.new("1.8.5") < Version.new("1.10.0")
=> true

I'd strongly suggest, that it's much better for Ruby if it tries to
stay in line as much as possible with how things are done in the open
source community.

There's a lot of software outside of Ruby which depends on having
versions being a tuple of numbers. Since Ruby makes it easy to meet
things like that more than halfway, I think that it's better to do so.

but this isn't correct by 'open source' standards

http://codeforpeople.com/lib/ruby/library/library-0.0.0/doc/
http://sources.redhat.com/autobook/autobook/autobook_91.html

in order to compare you have to consider the semantics of each positional
number


-a

 

[Rick DeNatale]

"1.8.5" < "1.10.0"
=> false

Ah, but doing the comparison correctly in Ruby isn't that hard, in a
few minutes I came up with:

irb(main):023:0> class Version
irb(main):024:1> include Comparable
irb(main):025:1>
irb(main):026:1* def initialize(string)
irb(main):027:2> @value = string.split('.').collect { | i | i.to_i }
irb(main):028:2> end
irb(main):029:1>
irb(main):030:1* def <=>(another)
irb(main):031:2> @value <=> another.to_ary
irb(main):032:2> end
irb(main):033:1>
irb(main):034:1* def to_ary
irb(main):035:2> @value
irb(main):036:2> end
irb(main):037:1> end
=> nil
irb(main):038:0> Version.new("1.8.5")
=> #<Version:0xb7d728e8 @value=[1, 8, 5]>
irb(main):039:0> Version.new("1.8.5") < Version.new("1.10.0")
=> true

I'd strongly suggest, that it's much better for Ruby if it tries to
stay in line as much as possible with how things are done in the open
source community.

There's a lot of software outside of Ruby which depends on having
versions being a tuple of numbers. Since Ruby makes it easy to meet
things like that more than halfway, I think that it's better to do so.

but this isn't correct by 'open source' standards

http://codeforpeople.com/lib/ruby/library/library-0.0.0/doc/
http://sources.redhat.com/autobook/autobook/autobook_91.html

in order to compare you have to consider the semantics of each positional
number

I'm not sure I see the point. Each level has less signficance than
the one before. I'm pretty sure that's how the code I posted orders
versions.


--
Rick DeNatale

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Next Major Version (was Re: Different semantics of Proc and method call -- bug or feature?)"

|> The version letters will be stay in one letter each, so that 1.a will
|> be more likely than 1.10.

|Matz,
|
|I hesitate to ask YOU this, but are you really sure you want to go that way.
|
|Almost every software package I've run across keeps each level of the
|version "number" as a number, so 1.10 would be much more in line with
|standard practice than 1.a

Ah, well, I forgot to put smiley after the sentence. No, we are not
going to name it neither "1.a" nor "1.10". 1.8.9 will be the last
release of the current stable series. And 1.9 will be the last of the
1.x.

matz.

 

[ara.t.howard]

I'm not sure I see the point. Each level has less signficance than
the one before. I'm pretty sure that's how the code I posted orders
versions.

you are right about that - i gues i was simply pointing out that, in order to
be correct with present open source standards one needs something that works
like

version('1.2.1') =~ version('1.1.0') #=> true

in otherwords, you need compaisson which implies compatibility, not just gt
and lt.

regards.

-a