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

Multi dispatch and generics don't mix #704

Closed
p6rt opened this issue Feb 17, 2009 · 6 comments
Closed

Multi dispatch and generics don't mix #704

p6rt opened this issue Feb 17, 2009 · 6 comments

Comments

@p6rt
Copy link

p6rt commented Feb 17, 2009

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

Searchable as RT63276$

@p6rt
Copy link
Author

p6rt commented Feb 17, 2009

From @moritz

Parrot r36678, Rakudo 0f87695c​:

  class Scissor { };
  class Paper { };
  class Stone { };

  multi wins(Scissor $x, Paper $y) { 1 };
  multi wins(Paper $x, Stone $y) { 1 };
  multi wins(Stone $x, Scissor $y) { 1 };
  multi wins(​::T $x, T $y) { 0 };
  multi wins($x, $y) { -1 };

  say wins(Scissor.new, Paper.new);
  # dies with 'Null PMC access in find_method()'
  say wins(Paper.new, Paper.new);
  # same, if moved further up
  say wins(Stone.new, Paper.new);

I think this is also a bug, not 100% sure though​:

  ./perl6 -e 'multi f(​::T $x, T $y) { "first" }; multi f(Int $x, Num
$y) { "second" }; say f(1, 2)'
  # output​: second

P.S.​: it would be nice if this bug could be fixed quickly, since I want
to use this code in an article for a fairly big IT magazine, and the
submission deadline is end of February. So if you fix this soon, we'll
get lots of good publicity cookies ;-)

--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/

@p6rt
Copy link
Author

p6rt commented Feb 17, 2009

From @moritz

On Tue Feb 17 00​:07​:07 2009, mlenz@​physik.uni-wuerzburg.de wrote​:

Parrot r36678, Rakudo 0f87695c​:

class Scissor \{ \};
class Paper   \{ \};
class Stone   \{ \};

multi wins\(Scissor $x, Paper   $y\) \{ 1 \};
multi wins\(Paper   $x, Stone   $y\) \{ 1 \};
multi wins\(Stone   $x, Scissor $y\) \{ 1 \};
multi wins\(​::T     $x, T       $y\) \{ 0 \};
multi wins\($x, $y\) \{ \-1 \};

say wins\(Scissor\.new, Paper\.new\);
\# dies with 'Null PMC access in find\_method\(\)'
say wins\(Paper\.new,   Paper\.new\);
\# same, if moved further up
say wins\(Stone\.new,   Paper\.new\);

I've added those as tests to S06-multi/type-based.t (currently fudged)

Cheers,
Moritz

@p6rt
Copy link
Author

p6rt commented Feb 17, 2009

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

@p6rt
Copy link
Author

p6rt commented Feb 17, 2009

From @jnthn

Moritz Lenz wrote​:

Parrot r36678, Rakudo 0f87695c​:

class Scissor \{ \};
class Paper   \{ \};
class Stone   \{ \};

multi wins\(Scissor $x, Paper   $y\) \{ 1 \};
multi wins\(Paper   $x, Stone   $y\) \{ 1 \};
multi wins\(Stone   $x, Scissor $y\) \{ 1 \};
multi wins\(​::T     $x, T       $y\) \{ 0 \};
multi wins\($x, $y\) \{ \-1 \};

say wins\(Scissor\.new, Paper\.new\);
\# dies with 'Null PMC access in find\_method\(\)'
say wins\(Paper\.new,   Paper\.new\);
\# same, if moved further up
say wins\(Stone\.new,   Paper\.new\);

I think that's related to any lexically scoped thingy declared in the
signature and used during the type check.

I think this is also a bug, not 100% sure though​:

\./perl6 \-e 'multi f\(​::T $x, T $y\) \{ "first" \}; multi f\(Int $x, Num

$y) { "second" }; say f(1, 2)'
# output​: second

It's not. We do the sorting on what we statically know the types to be
(for some definition of statically, but the heart of it is "independent
of any particular call"). The type T that we capture is known on a
per-call basis, and as such we check it as a constraint, but it isn't a
part of the candidate sorting process. So at the candidate sorting level
it's like a :(Any, Any).

P.S.​: it would be nice if this bug could be fixed quickly, since I want to use this code in an article for a fairly big IT magazine, and the submission deadline is end of February. So if you fix this soon, we'll get lots of good publicity cookies ;-)

I'll try and do that - will see how my initial idea for the fix goes. It
just involves dealing with continuations, which is a little scary,
especially when there's C boundary issues...all quite a brain ache.

Thanks,

Jonathan

@p6rt
Copy link
Author

p6rt commented Jul 2, 2009

From @moritz

jnthn++ has fixed this, and I unfudged the tests. Peace and happiness
spreads over the world.

@p6rt
Copy link
Author

p6rt commented Jul 2, 2009

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

@p6rt p6rt closed this as completed Jul 2, 2009
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant