Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple dispatch doesn't treat 'rw' parameters as narrower than readonly parameters in Rakudo #1695

Closed
p6rt opened this issue Apr 16, 2010 · 6 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Apr 16, 2010

Migrated from rt.perl.org#74414 (status was 'resolved')

Searchable as RT74414$

@p6rt
Copy link
Author

p6rt commented Apr 16, 2010

From @masak

<masak> rakudo​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x) { "readonly" }; foo(42)
<p6eval> rakudo 78faa0​: OUTPUT«Ambiguous dispatch to multi 'foo'.
Ambiguous candidates had signatures​:␤​:(Int $x)␤​:(Int $x) [...]
* masak submits rakudobug
<masak> S06​: "To allow modification, use the C<is rw> trait. This
requires a mutable object or container as an argument (or some kind of
type object that can be converted to a mutable object, such as might
be returned by an array or hash that knows how to autovivify new
elements). Otherwise the signature fails to bind, and this candidate
routine cannot be considered for servicing this particular call.
(Other multi candidates, if any, may succeed if they don't require
C<rw> for this parameter.)"
<moritz_> now you're just showing off :-)
<masak> :P

@p6rt
Copy link
Author

p6rt commented Feb 23, 2014

From @coke

On Fri Apr 16 01​:31​:22 2010, masak wrote​:

<masak> rakudo​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x) { "readonly" }; foo(42)
<p6eval> rakudo 78faa0​: OUTPUT«Ambiguous dispatch to multi 'foo'.
Ambiguous candidates had signatures​:␤​:(Int $x)␤​:(Int $x) [...]
* masak submits rakudobug
<masak> S06​: "To allow modification, use the C<is rw> trait. This
requires a mutable object or container as an argument (or some kind of
type object that can be converted to a mutable object, such as might
be returned by an array or hash that knows how to autovivify new
elements). Otherwise the signature fails to bind, and this candidate
routine cannot be considered for servicing this particular call.
(Other multi candidates, if any, may succeed if they don't require
C<rw> for this parameter.)"
<moritz_> now you're just showing off :-)
<masak> :P

Behavior is mostly unchanged since 2010 - error message has better signature reporting, but still reported as ambiguous.

20​:36 <[Coke]> m​: multi foo(Int $x is rw) { say "writable" }; multi foo(Int $x)
  { "readonly" }; foo(42)
20​:36 <camelia> rakudo-moar b2b333​: OUTPUT«Ambiguous call to 'foo'; these
  signatures all match​:␤​:(Int $x is rw)␤​:(Int $x)␤ in sub foo at
  /tmp/CwM3ZkL1nu​:1␤ in block at /tmp/CwM3ZkL1nu​:1␤␤»
--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Feb 23, 2014

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Nov 10, 2015

From @peschwa

On Sat Feb 22 17​:37​:47 2014, coke wrote​:

On Fri Apr 16 01​:31​:22 2010, masak wrote​:

<masak> rakudo​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x) { "readonly" }; foo(42)
<p6eval> rakudo 78faa0​: OUTPUT«Ambiguous dispatch to multi 'foo'.
Ambiguous candidates had signatures​:␤​:(Int $x)␤​:(Int $x) [...]
* masak submits rakudobug
<masak> S06​: "To allow modification, use the C<is rw> trait. This
requires a mutable object or container as an argument (or some kind
of
type object that can be converted to a mutable object, such as might
be returned by an array or hash that knows how to autovivify new
elements). Otherwise the signature fails to bind, and this candidate
routine cannot be considered for servicing this particular call.
(Other multi candidates, if any, may succeed if they don't require
C<rw> for this parameter.)"
<moritz_> now you're just showing off :-)
<masak> :P

Behavior is mostly unchanged since 2010 - error message has better
signature reporting, but still reported as ambiguous.

20​:36 <[Coke]> m​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x)
{ "readonly" }; foo(42)
20​:36 <camelia> rakudo-moar b2b333​: OUTPUT«Ambiguous call to 'foo';
these
signatures all match​:␤​:(Int $x is rw)␤​:(Int $x)␤ in
sub foo at
/tmp/CwM3ZkL1nu​:1␤ in block at /tmp/CwM3ZkL1nu​:1␤␤»

With Rakudo commits 8cba8863 and ed10656c this now behaves as follow​:

15​:52 < psch> m​: multi foo(Int $x is rw) { say "writable" }; multi foo(Int $x) { "readonly" }; say foo(42); foo my $ = 42;
15​:52 <+camelia> rakudo-moar ed1065​: OUTPUT«readonly␤writable␤»

I've also added S06-multi/by-trait.t to spectest.data which tests this.

@p6rt
Copy link
Author

p6rt commented Nov 13, 2015

From @jnthn

On Tue Nov 10 07​:55​:06 2015, peschwa@​gmail.com wrote​:

On Sat Feb 22 17​:37​:47 2014, coke wrote​:

On Fri Apr 16 01​:31​:22 2010, masak wrote​:

<masak> rakudo​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x) { "readonly" }; foo(42)
<p6eval> rakudo 78faa0​: OUTPUT«Ambiguous dispatch to multi 'foo'.
Ambiguous candidates had signatures​:␤​:(Int $x)␤​:(Int $x) [...]
* masak submits rakudobug
<masak> S06​: "To allow modification, use the C<is rw> trait. This
requires a mutable object or container as an argument (or some kind
of
type object that can be converted to a mutable object, such as
might
be returned by an array or hash that knows how to autovivify new
elements). Otherwise the signature fails to bind, and this
candidate
routine cannot be considered for servicing this particular call.
(Other multi candidates, if any, may succeed if they don't require
C<rw> for this parameter.)"
<moritz_> now you're just showing off :-)
<masak> :P

Behavior is mostly unchanged since 2010 - error message has better
signature reporting, but still reported as ambiguous.

20​:36 <[Coke]> m​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x)
{ "readonly" }; foo(42)
20​:36 <camelia> rakudo-moar b2b333​: OUTPUT«Ambiguous call to 'foo';
these
signatures all match​:␤​:(Int $x is rw)␤​:(Int $x)␤ in
sub foo at
/tmp/CwM3ZkL1nu​:1␤ in block at /tmp/CwM3ZkL1nu​:1␤␤»

With Rakudo commits 8cba8863 and ed10656c this now behaves as follow​:

15​:52 < psch> m​: multi foo(Int $x is rw) { say "writable" }; multi
foo(Int $x) { "readonly" }; say foo(42); foo my $ = 42;
15​:52 <+camelia> rakudo-moar ed1065​: OUTPUT«readonly␤writable␤»

I've also added S06-multi/by-trait.t to spectest.data which tests
this.

psch++ also updated most of the multi-dispatch caching logic to get things performing well again. Today I updated the dynamic optimizer in Moar to understand the new multi-dispatch flag, so we don't go mis-inlining. And fixed a further static optimizer issue where it wasn't aware of `is rw` and so could mis-dispatch. Both covered by more tests in S06-multi/by-trait.t.

So, we can consider this done.

/jnthn

@p6rt p6rt closed this as completed Nov 13, 2015
@p6rt
Copy link
Author

p6rt commented Nov 13, 2015

@jnthn - Status changed from 'open' to 'resolved'

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant