Skip Menu |
Report information
Id: 131791
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Custom class :D coersers don't work
Download (untitled) / with headers
text/plain 602b
The coercion works fine here: 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class B {}; sub foo(B() $b) { say "hi" }; foo(A.new) 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «hi?» But if I add `:D` smiley, it fails: 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class B {}; sub foo(B:D() $b) { say "hi" }; foo(A.new) 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «Type check failed in binding to parameter '$b'; expected B but got A (A.new)? in sub foo at <tmp> line 1? in block <unit> at <tmp> line 1??» https://irclog.perlgeek.de/perl6/2017-07-24#i_14915397
Subject: [SPEC] Coercers don't work with smiley types
Download (untitled) / with headers
text/plain 1.4k
On Mon, 24 Jul 2017 10:04:54 -0700, cpan@zoffix.com wrote: Show quoted text
> The coercion works fine here: > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class B > {}; sub foo(B() $b) { say "hi" }; foo(A.new) > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «hi?» > > But if I add `:D` smiley, it fails: > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class B > {}; sub foo(B:D() $b) { say "hi" }; foo(A.new) > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «Type check failed > in binding to parameter '$b'; expected B but got A (A.new)? in sub > foo at <tmp> line 1? in block <unit> at <tmp> line 1??» > > https://irclog.perlgeek.de/perl6/2017-07-24#i_14915397
Seems to be more generic than custom classes: $ perl6 -e 'sub foo(Int() $b) { say $b }; foo("42")' 42 $ perl6 -e 'sub foo(Int:D() $b) { say $b }; foo("42")' Type check failed in binding to parameter '$b'; expected Int but got Str ("42") in sub foo at -e line 1 in block <unit> at -e line 1 This raises the spec question, should e.g. IO:U($a) try to convert $a to an IO, and if that succeeds, succeed the bind with the type object of whatever doer (or subclass were IO a class) of IO which resulted? Or fail the bind? The latter is more consistent with the above desired behavior... but does "Class:D()" mean coerce-to-then-check-definedness, or go-all-out-to-make-a-defined-value? This doesn't make much sense yet either: $ perl6 -e 'Int:D(4).say' (Int:D)
Download (untitled) / with headers
text/plain 1.6k
On Wed, 23 Aug 2017 06:20:49 -0700, bri@abrij.org wrote: Show quoted text
> On Mon, 24 Jul 2017 10:04:54 -0700, cpan@zoffix.com wrote:
> > The coercion works fine here: > > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class > > B > > {}; sub foo(B() $b) { say "hi" }; foo(A.new) > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «hi?» > > > > But if I add `:D` smiley, it fails: > > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class > > B > > {}; sub foo(B:D() $b) { say "hi" }; foo(A.new) > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «Type check > > failed > > in binding to parameter '$b'; expected B but got A (A.new)? in sub > > foo at <tmp> line 1? in block <unit> at <tmp> line 1??» > > > > https://irclog.perlgeek.de/perl6/2017-07-24#i_14915397
> > Seems to be more generic than custom classes: > > $ perl6 -e 'sub foo(Int() $b) { say $b }; foo("42")' > 42 > $ perl6 -e 'sub foo(Int:D() $b) { say $b }; foo("42")' > Type check failed in binding to parameter '$b'; expected Int but got > Str ("42") > in sub foo at -e line 1 > in block <unit> at -e line 1 > > This raises the spec question, should e.g. IO:U($a) try to convert $a > to an IO, > and if that succeeds, succeed the bind with the type object of > whatever doer (or > subclass were IO a class) of IO which resulted? Or fail the bind? > The latter is > more consistent with the above desired behavior... but does > "Class:D()" mean > coerce-to-then-check-definedness, or go-all-out-to-make-a-defined- > value? > > This doesn't make much sense yet either: > > $ perl6 -e 'Int:D(4).say' > (Int:D)
This ticket and RT#126433 can be combined.
Download (untitled) / with headers
text/plain 3.2k
On Fri, 08 Sep 2017 21:13:59 -0700, bri@abrij.org wrote: Show quoted text
> On Wed, 23 Aug 2017 06:20:49 -0700, bri@abrij.org wrote:
> > On Mon, 24 Jul 2017 10:04:54 -0700, cpan@zoffix.com wrote:
> > > The coercion works fine here: > > > > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class > > > B > > > {}; sub foo(B() $b) { say "hi" }; foo(A.new) > > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «hi?» > > > > > > But if I add `:D` smiley, it fails: > > > > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; class > > > B > > > {}; sub foo(B:D() $b) { say "hi" }; foo(A.new) > > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «Type check > > > failed > > > in binding to parameter '$b'; expected B but got A (A.new)? in sub > > > foo at <tmp> line 1? in block <unit> at <tmp> line 1??» > > > > > > https://irclog.perlgeek.de/perl6/2017-07-24#i_14915397
> > > > Seems to be more generic than custom classes: > > > > $ perl6 -e 'sub foo(Int() $b) { say $b }; foo("42")' > > 42 > > $ perl6 -e 'sub foo(Int:D() $b) { say $b }; foo("42")' > > Type check failed in binding to parameter '$b'; expected Int but got > > Str ("42") > > in sub foo at -e line 1 > > in block <unit> at -e line 1 > > > > This raises the spec question, should e.g. IO:U($a) try to convert $a > > to an IO, > > and if that succeeds, succeed the bind with the type object of > > whatever doer (or > > subclass were IO a class) of IO which resulted? Or fail the bind? > > The latter is > > more consistent with the above desired behavior... but does > > "Class:D()" mean > > coerce-to-then-check-definedness, or go-all-out-to-make-a-defined- > > value? > > > > This doesn't make much sense yet either: > > > > $ perl6 -e 'Int:D(4).say' > > (Int:D)
> > > This ticket and RT#126433 can be combined.
I spent some more time digging into this. There are a couple layers to this issue. The first is a syntax conflict. Consider (example from specs): use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4); ...in order to parse that the generic "extended identifier" syntax is allowed to take a statement list as the value of a colonpair-in-a-name. This is somewhat more liberal than what is normally allowed in a coercion type. Now in the S02, "extended identifiers" are said to only allow a "subscript-like adverbial form", which would exclude parens as the circumfix, so one solution to this would be to restrict the above syntax to useish statements only, or some broader but still limited syntactic category. There seems to be some logic for this already in token term:sym<name>, but not in token typename, which is where this case ends up. The second issue bears on the spec issue I raised above: if you do manage to chop through the syntax issues, then you have to decide whether the class coercion method that is called is named "B" or "B:D"... having separate methods for all smiley types could be advantageous, but would be tedious. Perhaps looking for "B:D" and if not found, calling "B" instead would be something to consider here. To pile on that, we get to the (NYI) behavior where the adverbial components of an extended identifier are supposed to be orderless, along with the prospect for compound smileys to be added later... cross that bridge when we get there I guess.
Download (untitled) / with headers
text/plain 3.5k
On Sun, 10 Sep 2017 11:44:09 -0700, bri@abrij.org wrote: Show quoted text
> On Fri, 08 Sep 2017 21:13:59 -0700, bri@abrij.org wrote:
> > On Wed, 23 Aug 2017 06:20:49 -0700, bri@abrij.org wrote:
> > > On Mon, 24 Jul 2017 10:04:54 -0700, cpan@zoffix.com wrote:
> > > > The coercion works fine here: > > > > > > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; > > > > class > > > > B > > > > {}; sub foo(B() $b) { say "hi" }; foo(A.new) > > > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «hi?» > > > > > > > > But if I add `:D` smiley, it fails: > > > > > > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }}; > > > > class > > > > B > > > > {}; sub foo(B:D() $b) { say "hi" }; foo(A.new) > > > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «Type check > > > > failed > > > > in binding to parameter '$b'; expected B but got A (A.new)? in > > > > sub > > > > foo at <tmp> line 1? in block <unit> at <tmp> line 1??» > > > > > > > > https://irclog.perlgeek.de/perl6/2017-07-24#i_14915397
> > > > > > Seems to be more generic than custom classes: > > > > > > $ perl6 -e 'sub foo(Int() $b) { say $b }; foo("42")' > > > 42 > > > $ perl6 -e 'sub foo(Int:D() $b) { say $b }; foo("42")' > > > Type check failed in binding to parameter '$b'; expected Int but > > > got > > > Str ("42") > > > in sub foo at -e line 1 > > > in block <unit> at -e line 1 > > > > > > This raises the spec question, should e.g. IO:U($a) try to convert > > > $a > > > to an IO, > > > and if that succeeds, succeed the bind with the type object of > > > whatever doer (or > > > subclass were IO a class) of IO which resulted? Or fail the bind? > > > The latter is > > > more consistent with the above desired behavior... but does > > > "Class:D()" mean > > > coerce-to-then-check-definedness, or go-all-out-to-make-a-defined- > > > value? > > > > > > This doesn't make much sense yet either: > > > > > > $ perl6 -e 'Int:D(4).say' > > > (Int:D)
> > > > > > This ticket and RT#126433 can be combined.
> > > I spent some more time digging into this. There are a couple layers > to this issue. > > The first is a syntax conflict. Consider (example from specs): > > use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4); > > ...in order to parse that the generic "extended identifier" syntax is > allowed to > take a statement list as the value of a colonpair-in-a-name. This is > somewhat > more liberal than what is normally allowed in a coercion type. > > Now in the S02, "extended identifiers" are said to only allow a > "subscript-like adverbial form", which would exclude parens as the > circumfix, > so one solution to this would be to restrict the above syntax to > useish statements only, or some broader but still limited syntactic > category. There seems to be some logic for this already in token > term:sym<name>, > but not in token typename, which is where this case ends up. > > The second issue bears on the spec issue I raised above: if you do > manage to > chop through the syntax issues, then you have to decide whether the > class > coercion method that is called is named "B" or "B:D"... having > separate > methods for all smiley types could be advantageous, but would be > tedious. > Perhaps looking for "B:D" and if not found, calling "B" instead would > be > something to consider here. > > To pile on that, we get to the (NYI) behavior where the adverbial > components > of an extended identifier are supposed to be orderless, along with the > prospect > for compound smileys to be added later... cross that bridge when we > get there I guess.
When fixing, please note also RT#130657


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org