* [ruby-core:90767] [Ruby trunk Bug#15477] Proc#arity returns -1 for composed lambda Procs of known arguments [not found] <redmine.issue-15477.20181228052759@ruby-lang.org> @ 2018-12-28 5:28 ` robb+ruby 2019-01-01 11:09 ` [ruby-core:90842] [Ruby trunk Feature#15477] " mame ` (2 subsequent siblings) 3 siblings, 0 replies; 4+ messages in thread From: robb+ruby @ 2018-12-28 5:28 UTC (permalink / raw) To: ruby-core Issue #15477 has been reported by robb (Robb Shecter). ---------------------------------------- Bug #15477: Proc#arity returns -1 for composed lambda Procs of known arguments https://bugs.ruby-lang.org/issues/15477 * Author: robb (Robb Shecter) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- ``` f = -> x { x + 2 } g = -> x { x * 2 } h = f << g f.arity # => 1 g.arity # => 1 h.arity # => -1 THIS SHOULD BE 1 because h "knows" that it takes exactly 1 argument: h.call # => ArgumentError (given 0, expected 1) ``` Lambda Procs which are composed using `<<` seem to partially lose knowledge of their arity. I don't know if this affects other procs, or the `>>` operator as well. The Proc#arity docs state that -1 is returned only when a variable or unknown number of arguments are expected by the Proc. But here, that's not the case. -- https://bugs.ruby-lang.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* [ruby-core:90842] [Ruby trunk Feature#15477] Proc#arity returns -1 for composed lambda Procs of known arguments [not found] <redmine.issue-15477.20181228052759@ruby-lang.org> 2018-12-28 5:28 ` [ruby-core:90767] [Ruby trunk Bug#15477] Proc#arity returns -1 for composed lambda Procs of known arguments robb+ruby @ 2019-01-01 11:09 ` mame 2019-01-10 8:04 ` [ruby-core:90978] " matz 2019-03-15 12:39 ` [ruby-core:91849] " mathias 3 siblings, 0 replies; 4+ messages in thread From: mame @ 2019-01-01 11:09 UTC (permalink / raw) To: ruby-core Issue #15477 has been updated by mame (Yusuke Endoh). Tracker changed from Bug to Feature ruby -v deleted (ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux]) Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN) Looks not a bug to me. Moving to the feature tracker. A patch is attached. ```diff diff --git a/proc.c b/proc.c index c09e845ec0..45e2a21551 100644 --- a/proc.c +++ b/proc.c @@ -3063,6 +3063,16 @@ compose(VALUE dummy, VALUE args, int argc, VALUE *argv, VALUE passed_proc) return rb_funcallv(f, idCall, 1, &fargs); } +static VALUE +compose_proc_new(VALUE procs) +{ + VALUE first_proc = RARRAY_AREF(procs, 1); + int max_arity, min_arity = rb_proc_min_max_arity(first_proc, &max_arity); + int lambda_p = rb_proc_lambda_p(first_proc); + struct vm_ifunc *ifunc = rb_vm_ifunc_new((rb_block_call_func_t) compose, (void *)procs, min_arity, max_arity); + return cfunc_proc_new(rb_cProc, (VALUE)ifunc, lambda_p); +} + /* * call-seq: * prc << g -> a_proc @@ -3089,7 +3099,7 @@ proc_compose_to_left(VALUE self, VALUE g) GetProcPtr(self, procp); is_lambda = procp->is_lambda; - proc = rb_proc_new(compose, args); + proc = compose_proc_new(args); GetProcPtr(proc, procp); procp->is_lambda = is_lambda; @@ -3122,7 +3132,7 @@ proc_compose_to_right(VALUE self, VALUE g) GetProcPtr(self, procp); is_lambda = procp->is_lambda; - proc = rb_proc_new(compose, args); + proc = compose_proc_new(args); GetProcPtr(proc, procp); procp->is_lambda = is_lambda; ``` ---------------------------------------- Feature #15477: Proc#arity returns -1 for composed lambda Procs of known arguments https://bugs.ruby-lang.org/issues/15477#change-76031 * Author: robb (Robb Shecter) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- ``` f = -> x { x + 2 } g = -> x { x * 2 } h = f << g f.arity # => 1 g.arity # => 1 h.arity # => -1 THIS SHOULD BE 1 because h "knows" that it takes exactly 1 argument: h.call # => ArgumentError (given 0, expected 1) ``` Lambda Procs which are composed using `<<` seem to partially lose knowledge of their arity. I don't know if this affects other procs, or the `>>` operator as well. The Proc#arity docs state that -1 is returned only when a variable or unknown number of arguments are expected by the Proc. But here, that's not the case. -- https://bugs.ruby-lang.org/ ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [ruby-core:90978] [Ruby trunk Feature#15477] Proc#arity returns -1 for composed lambda Procs of known arguments [not found] <redmine.issue-15477.20181228052759@ruby-lang.org> 2018-12-28 5:28 ` [ruby-core:90767] [Ruby trunk Bug#15477] Proc#arity returns -1 for composed lambda Procs of known arguments robb+ruby 2019-01-01 11:09 ` [ruby-core:90842] [Ruby trunk Feature#15477] " mame @ 2019-01-10 8:04 ` matz 2019-03-15 12:39 ` [ruby-core:91849] " mathias 3 siblings, 0 replies; 4+ messages in thread From: matz @ 2019-01-10 8:04 UTC (permalink / raw) To: ruby-core Issue #15477 has been updated by matz (Yukihiro Matsumoto). Yes, please. Matz. ---------------------------------------- Feature #15477: Proc#arity returns -1 for composed lambda Procs of known arguments https://bugs.ruby-lang.org/issues/15477#change-76191 * Author: robb (Robb Shecter) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- ``` f = -> x { x + 2 } g = -> x { x * 2 } h = f << g f.arity # => 1 g.arity # => 1 h.arity # => -1 THIS SHOULD BE 1 because h "knows" that it takes exactly 1 argument: h.call # => ArgumentError (given 0, expected 1) ``` Lambda Procs which are composed using `<<` seem to partially lose knowledge of their arity. I don't know if this affects other procs, or the `>>` operator as well. The Proc#arity docs state that -1 is returned only when a variable or unknown number of arguments are expected by the Proc. But here, that's not the case. -- https://bugs.ruby-lang.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* [ruby-core:91849] [Ruby trunk Feature#15477] Proc#arity returns -1 for composed lambda Procs of known arguments [not found] <redmine.issue-15477.20181228052759@ruby-lang.org> ` (2 preceding siblings ...) 2019-01-10 8:04 ` [ruby-core:90978] " matz @ 2019-03-15 12:39 ` mathias 3 siblings, 0 replies; 4+ messages in thread From: mathias @ 2019-03-15 12:39 UTC (permalink / raw) To: ruby-core Issue #15477 has been updated by majjoha (Mathias Jean Johansen). For what it is worth, this appears to be an issue when dealing with curried procs as well. ``` ruby curried_proc = ->(a, b) { a + b }.curry # => <Proc:0x00007fa7698e7700 (lambda)> first = curried_proc.(1) # => <Proc:0x00007fa76991a0d8 (lambda)> curried_proc.arity # => -1 first.arity # => -1 ``` ---------------------------------------- Feature #15477: Proc#arity returns -1 for composed lambda Procs of known arguments https://bugs.ruby-lang.org/issues/15477#change-77120 * Author: robb (Robb Shecter) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- ``` f = -> x { x + 2 } g = -> x { x * 2 } h = f << g f.arity # => 1 g.arity # => 1 h.arity # => -1 THIS SHOULD BE 1 because h "knows" that it takes exactly 1 argument: h.call # => ArgumentError (given 0, expected 1) ``` Lambda Procs which are composed using `<<` seem to partially lose knowledge of their arity. I don't know if this affects other procs, or the `>>` operator as well. The Proc#arity docs state that -1 is returned only when a variable or unknown number of arguments are expected by the Proc. But here, that's not the case. -- https://bugs.ruby-lang.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-03-15 12:39 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-15477.20181228052759@ruby-lang.org> 2018-12-28 5:28 ` [ruby-core:90767] [Ruby trunk Bug#15477] Proc#arity returns -1 for composed lambda Procs of known arguments robb+ruby 2019-01-01 11:09 ` [ruby-core:90842] [Ruby trunk Feature#15477] " mame 2019-01-10 8:04 ` [ruby-core:90978] " matz 2019-03-15 12:39 ` [ruby-core:91849] " mathias
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).