Different semantics of Proc and method call -- bug or featur

Ruby
#1

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

#2

Tammo F. wrote:

end

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]
=> nil

t {|a,*b| p a}
1
2
3
=> nil

t {|a,| p a}
1
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
#3

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

#4

Hi,

In message “Re: Different semantics of Proc and method call – bug or
feature?”
on Wed, 2 Aug 2006 21:35:05 +0900, Tammo F. [email protected]
writes:

|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.
#5

Hi,

In message “Re: Next Major Version (was Re: Different semantics of Proc
and method call – bug or feature?)”
on Wed, 2 Aug 2006 23:14:32 +0900, James Edward G. II
[email protected] writes:

|On Aug 2, 2006, at 9:05 AM, Yukihiro M. 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.
#6

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

#7

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

:wink:

M.T.

#8

On Aug 2, 2006, at 9:05 AM, Yukihiro M. 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?

James Edward G. II

#9

Hi,

In message “Re: Next Major Version (was Re: Different semantics of Proc
and method call – bug or feature?)”
on Thu, 3 Aug 2006 00:38:41 +0900, “N Okia” [email protected]
writes:

|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.
#10

On 8/2/06, Yukihiro M. [email protected] wrote:

                                                    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

#11

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

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:

“1.8.5” < “1.10.0”
=> false

James Edward G. II

#12

On 8/3/06, James Edward G. II [email protected] wrote:

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

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

=> 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/

#13

On Fri, 4 Aug 2006, Rick DeNatale wrote:

irb(main):027:2> @value = string.split(’.’).collect { | i | i.to_i }
=> nil
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

#14

James Edward G. II wrote:

|In keeping with your current numbering scheme, does this mean there
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:

“1.8.5” < “1.10.0”
=> false

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

T.

#15

On 8/3/06, [email protected] [email protected] wrote:

irb(main):025:1>
irb(main):036:2> end

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/

#16

Hi,

In message “Re: Next Major Version (was Re: Different semantics of Proc
and method call – bug or feature?)”
on Fri, 4 Aug 2006 00:26:39 +0900, “Rick DeNatale”
[email protected] writes:

|> 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.
#17

On Fri, 4 Aug 2006, Rick DeNatale wrote:

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