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

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

Tammo Freese wrote:

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

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

···

On Aug 2, 2006, at 8:35 AM, Tammo Freese wrote:

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

Hi,

···

In message "Re: Different semantics of Proc and method call -- bug or feature?" on Wed, 2 Aug 2006 21:35:05 +0900, Tammo Freese <freese@acm.org> 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.

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

···

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).

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 Gray II <james@grayproductions.net> writes:

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.

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

···

On 8/2/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

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 Gray II <james@grayproductions.net> writes:

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

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

:wink:

M.T.

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" <wrecklass1@gmail.com> 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.

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

···

On 8/2/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

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" <wrecklass1@gmail.com> 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.

--
Rick DeNatale

Hi,

>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

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

>> "1.8.5" < "1.10.0"
=> false

James Edward Gray II

···

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

On 8/2/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

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" >> <wrecklass1@gmail.com> writes:

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" <rick.denatale@gmail.com> 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.

James Edward Gray II wrote:

···

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

> On 8/2/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>> 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" > >> <wrecklass1@gmail.com> 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.
>
> 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:

>> "1.8.5" < "1.10.0"
=> false

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

T.

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.

···

On 8/3/06, James Edward Gray II <james@grayproductions.net> 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.

> 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:

>> "1.8.5" < "1.10.0"
=> false

--
Rick DeNatale

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

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

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

···

On Fri, 4 Aug 2006, Rick DeNatale wrote:

>> "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.

--
we can never obtain peace in the outer world until we make peace with
ourselves.
- h.h. the 14th dali lama

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.

···

On 8/3/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:

On Fri, 4 Aug 2006, Rick DeNatale wrote:

>> >> "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

--
Rick DeNatale

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

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

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

···

On Fri, 4 Aug 2006, Rick DeNatale wrote:

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.

--
we can never obtain peace in the outer world until we make peace with
ourselves.
- h.h. the 14th dali lama