* [ruby-core:90135] [Ruby trunk Bug#15357] Unify proc{} and lambda{}.parameters
[not found] <redmine.issue-15357.20181128200114@ruby-lang.org>
@ 2018-11-28 20:01 ` lars
2019-08-28 2:12 ` [ruby-core:94625] [Ruby master Feature#15357] Proc#parameters returns incomplete type information merch-redmine
` (2 subsequent siblings)
3 siblings, 0 replies; 4+ messages in thread
From: lars @ 2018-11-28 20:01 UTC (permalink / raw)
To: ruby-core
Issue #15357 has been reported by larskanis (Lars Kanis).
----------------------------------------
Bug #15357: Unify proc{} and lambda{}.parameters
https://bugs.ruby-lang.org/issues/15357
* Author: larskanis (Lars Kanis)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
The current implementation of Proc#parameters [differentiate between lambda? true and false](https://github.com/ruby/ruby/blob/49cd16bfaf4f03885058ce748119bc8ea2de735a/iseq.c#L2800).
This is presumably due to the fact, that [procs use tricks](https://ruby-doc.org/core-2.5.3/Proc.html#method-i-parameters) to apply arguments differently than lambda and methods.
Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable.
This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently:
```ruby
pr = proc{|a,b=2| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [:a, 2] # :a is interpret as the first parameter
pr = proc{|a=1,b| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [1, :a] # :a is interpret as the second parameter
```
That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc.
In Eventbox I use the workaround to pass the proc to `define_method` and [query the method parameters instead](https://github.com/larskanis/eventbox/blob/3bcbc30096c6003e96d41c6496c781dfc90ac36a/lib/eventbox/argument_wrapper.rb#L10-L17).
That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built.
The application of argument assignment tricks are a property of the Proc object, but not a property of single parameters.
The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well.
My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` returns `:req` arguments as well.
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ruby-core:94625] [Ruby master Feature#15357] Proc#parameters returns incomplete type information
[not found] <redmine.issue-15357.20181128200114@ruby-lang.org>
2018-11-28 20:01 ` [ruby-core:90135] [Ruby trunk Bug#15357] Unify proc{} and lambda{}.parameters lars
@ 2019-08-28 2:12 ` merch-redmine
2020-01-14 10:11 ` [ruby-core:96846] " lars
2020-01-14 13:21 ` [ruby-core:96855] " eregontp
3 siblings, 0 replies; 4+ messages in thread
From: merch-redmine @ 2019-08-28 2:12 UTC (permalink / raw)
To: ruby-core
Issue #15357 has been updated by jeremyevans0 (Jeremy Evans).
Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN)
ruby -v deleted (ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux])
Tracker changed from Bug to Feature
File proc-parameters-req-15357.patch added
I don't think the current behavior is a bug, as the parameters for a non-lambda proc are optional. Also, changing the behavior could be backwards incompatible.
I propose instead a `lambda` keyword to `Proc#parameters`, which would return the parameters as if the proc were a lambda. Attached is a patch that implements this.
----------------------------------------
Feature #15357: Proc#parameters returns incomplete type information
https://bugs.ruby-lang.org/issues/15357#change-81217
* Author: larskanis (Lars Kanis)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
The current implementation of Proc#parameters [differentiate between lambda? true and false](https://github.com/ruby/ruby/blob/49cd16bfaf4f03885058ce748119bc8ea2de735a/iseq.c#L2800).
This is presumably due to the fact, that [procs use tricks](https://ruby-doc.org/core-2.5.3/Proc.html#method-i-parameters) to apply arguments differently than lambda and methods.
Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable. This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently:
```ruby
pr = proc{|a,b=2| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [:a, 2] # :a is interpret as the first parameter
pr = proc{|a=1,b| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [1, :a] # :a is interpret as the second parameter
```
That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc. In Eventbox a workaround is used: The proc is passed to `define_method` and the [method parameters are retrieved instead](https://github.com/larskanis/eventbox/blob/3bcbc30096c6003e96d41c6496c781dfc90ac36a/lib/eventbox/argument_wrapper.rb#L10-L17). That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built.
The application of argument assignment tricks is a property of the Proc object - not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition - at least not in a way that discards valuable information. The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well.
My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` shows positional arguments without default value as type `:req` as well.
---Files--------------------------------
proc-parameters-req-15357.patch (5.15 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ruby-core:96846] [Ruby master Feature#15357] Proc#parameters returns incomplete type information
[not found] <redmine.issue-15357.20181128200114@ruby-lang.org>
2018-11-28 20:01 ` [ruby-core:90135] [Ruby trunk Bug#15357] Unify proc{} and lambda{}.parameters lars
2019-08-28 2:12 ` [ruby-core:94625] [Ruby master Feature#15357] Proc#parameters returns incomplete type information merch-redmine
@ 2020-01-14 10:11 ` lars
2020-01-14 13:21 ` [ruby-core:96855] " eregontp
3 siblings, 0 replies; 4+ messages in thread
From: lars @ 2020-01-14 10:11 UTC (permalink / raw)
To: ruby-core
Issue #15357 has been updated by larskanis (Lars Kanis).
Sorry for my late answer! I didn't get a notification mail.
As noted above: The application of argument assignment tricks is a property of the Proc object - not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition to `Proc#lambda?` . I therefore think it's kind of bug.
Nevertheless your patch looks like a good alternative, which keeps backward compatibility and doesn't discard information when called as `proc.parameters(lambda:true)`. Would you still mind to merge it?
----------------------------------------
Feature #15357: Proc#parameters returns incomplete type information
https://bugs.ruby-lang.org/issues/15357#change-83850
* Author: larskanis (Lars Kanis)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
The current implementation of Proc#parameters [differentiate between lambda? true and false](https://github.com/ruby/ruby/blob/49cd16bfaf4f03885058ce748119bc8ea2de735a/iseq.c#L2800).
This is presumably due to the fact, that [procs use tricks](https://ruby-doc.org/core-2.5.3/Proc.html#method-i-parameters) to apply arguments differently than lambda and methods.
Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable. This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently:
```ruby
pr = proc{|a,b=2| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [:a, 2] # :a is interpret as the first parameter
pr = proc{|a=1,b| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [1, :a] # :a is interpret as the second parameter
```
That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc. In Eventbox a workaround is used: The proc is passed to `define_method` and the [method parameters are retrieved instead](https://github.com/larskanis/eventbox/blob/3bcbc30096c6003e96d41c6496c781dfc90ac36a/lib/eventbox/argument_wrapper.rb#L10-L17). That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built.
The application of argument assignment tricks is a property of the Proc object - not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition - at least not in a way that discards valuable information. The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well.
My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` shows positional arguments without default value as type `:req` as well.
---Files--------------------------------
proc-parameters-req-15357.patch (5.15 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ruby-core:96855] [Ruby master Feature#15357] Proc#parameters returns incomplete type information
[not found] <redmine.issue-15357.20181128200114@ruby-lang.org>
` (2 preceding siblings ...)
2020-01-14 10:11 ` [ruby-core:96846] " lars
@ 2020-01-14 13:21 ` eregontp
3 siblings, 0 replies; 4+ messages in thread
From: eregontp @ 2020-01-14 13:21 UTC (permalink / raw)
To: ruby-core
Issue #15357 has been updated by Eregon (Benoit Daloze).
I agree, and discussed that a bit in #16499.
I think Proc#parameters should expose source-level information, not interpret it according to Kernel#lambda?.
----------------------------------------
Feature #15357: Proc#parameters returns incomplete type information
https://bugs.ruby-lang.org/issues/15357#change-83865
* Author: larskanis (Lars Kanis)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
The current implementation of Proc#parameters [differentiate between lambda? true and false](https://github.com/ruby/ruby/blob/49cd16bfaf4f03885058ce748119bc8ea2de735a/iseq.c#L2800).
This is presumably due to the fact, that [procs use tricks](https://ruby-doc.org/core-2.5.3/Proc.html#method-i-parameters) to apply arguments differently than lambda and methods.
Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable. This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently:
```ruby
pr = proc{|a,b=2| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [:a, 2] # :a is interpret as the first parameter
pr = proc{|a=1,b| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [1, :a] # :a is interpret as the second parameter
```
That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc. In Eventbox a workaround is used: The proc is passed to `define_method` and the [method parameters are retrieved instead](https://github.com/larskanis/eventbox/blob/3bcbc30096c6003e96d41c6496c781dfc90ac36a/lib/eventbox/argument_wrapper.rb#L10-L17). That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built.
The application of argument assignment tricks is a property of the Proc object - not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition - at least not in a way that discards valuable information. The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well.
My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` shows positional arguments without default value as type `:req` as well.
---Files--------------------------------
proc-parameters-req-15357.patch (5.15 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-14 13:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <redmine.issue-15357.20181128200114@ruby-lang.org>
2018-11-28 20:01 ` [ruby-core:90135] [Ruby trunk Bug#15357] Unify proc{} and lambda{}.parameters lars
2019-08-28 2:12 ` [ruby-core:94625] [Ruby master Feature#15357] Proc#parameters returns incomplete type information merch-redmine
2020-01-14 10:11 ` [ruby-core:96846] " lars
2020-01-14 13:21 ` [ruby-core:96855] " eregontp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).