Re: Types for Perl 6: request for comments
Now that I've read ahead to 3.4, the multi method solution shown can be a little simpler, just need to add multi to the original equal methods, see attached. -y On Tue, Jun 30, 2015 at 4:16 PM, yary not@gmail.com wrote: Section 3.2's example does not fail for the given reason This tries to access the c instance variable of the argument $b thus yielding a run-time error - instead Perl6 more correctly complains that it was expecting a ColPoint, but got a Point instead. Indeed one cannot generally replace a subtype with its parent type, only the other way around. Can correct by re-writing along the lines of This fails to dispatch because ColPoint's equal method requires a ColPoint argument, but we are calling it with the supertype Point, which does not compose with the method's signature. (Furthermore if equal is defined as a multi method, then the dispatcher chooses Point's equal method, and the example returns True, which all looks good to me. But it doesn't illustrate the paper's point.) -y Point.p6 Description: Binary data
Re: Types for Perl 6: request for comments
Section 3.2's example does not fail for the given reason This tries to access the c instance variable of the argument $b thus yielding a run-time error - instead Perl6 more correctly complains that it was expecting a ColPoint, but got a Point instead. Indeed one cannot generally replace a subtype with its parent type, only the other way around. Can correct by re-writing along the lines of This fails to dispatch because ColPoint's equal method requires a ColPoint argument, but we are calling it with the supertype Point, which does not compose with the method's signature. (Furthermore if equal is defined as a multi method, then the dispatcher chooses Point's equal method, and the example returns True, which all looks good to me. But it doesn't illustrate the paper's point.) -y
Re: Types for Perl 6: request for comments
On Fri, Jun 26, 2015 at 4:32 AM, Giuseppe Castagna g...@pps.univ-paris-diderot.fr wrote: my $sub = do { proto foo (|) { * } multi foo (Int $x) { $x + 1 } multi foo (Str $y) { $y ~ 'a' } foo; } Oh yes, nice ... I think I will add it in my paper (and if you send me your full name I will give credits to you) The do block version to make anonymous sub was my work, Brent Laabs. Using lexical subs to emulate anonymous multi subs was the first thing to come to mind when I read that Perl 6 didn't have them. Unfortunately, I haven't had time to read the rest of your paper, maybe this weekend.
Re: Types for Perl 6: request for comments
On 24/06/15 21:27, yary wrote: I'm reading it a bit at a time on lunch break, thanks for sending it along, it's educational. My comments here are all about the example on the top of page 5, starting with the minutest. First a typo, it says subC where it should say sumC multi sub sumB is ambiguous, due to your use of ;; there. And sumI /should/ be ambiguous, because the caller sumC(Int $x ;; $y) {sumI($x,$y)} means sumI will always be called with $x - Int and varying $y. That example could use a little re-working. Oh, right, Thank you, I apologize, I did some cutpaste errors in this code (I run all the code on rakudo but I must have missed this one). Here you are the correct version. I updated the paper online multi sub sumI(Int $y ;; Int $x){ $x + $y } multi sub sumI(Bool $y ;; Int $x) { sumC($y,$x)} multi sub sumB(Bool $y ;; Bool $x) { $x $y } multi sub sumB(Int $y ;; Bool $x) { sumC($x,$y0) } multi sub sumC(Int $x ;; Int|Bool $y) { sumI($y,$x) } multi sub sumC(Bool $x ;; Int|Bool $y) { sumB($y,$x) } I also added an explaination ... now it should be clearer. Note to Rakudo-porters: Can the error message remember the ;; in the sig ? The message from Rakudo * has a , where the source has ;; which is misleading: Ambiguous call to 'sumB'; these signatures all match: :(Bool $y, Bool $x) :(Bool $y, Int $x) The comment example about considering anonymous multi definitions in the same block to define the same anonymous function does show the feature's desirability, but that proposed syntax might be problematic. (Deciding if how to make that part of the syntax is not in the scope of the paper, but since you brought it up) What if one wants to define two different anonymous multi subs in the same scope? A contrived example: sub pick_multi (Bool $p) { my multi sub hmmI(Int $y) { 2 * $y } my multi sub hmmI(Bool $y) { $y } my multi sub hmmB(Int $y) { 1 + $y } my multi sub hmmB(Bool $y) { ! $y } $p ?? hmmI !! hmmB } Yes, one could enclose each anon-multi-set in a do block, but it feels to me that defining an anonymous multi-sub should require a single statement, to avoid unintentional co-mingling within a block. I see, but my purpose was completely different. I did not want define local multi-subroutines, I want to define a function whose *result* is a multi subroutine. So the intended meaning of multi sub sumC(Int $x){ multi sub (Int $y) { $x + $y } multi sub (Bool $y) { sumC ($y)($x) } } is multi sub sumC(Int $x){ return { multi sub (Int $y) { $x + $y } multi sub (Bool $y) { sumC ($y)($x) } } } in the same way as multi sub sumC(Int $x){ sub (Int $y){$x + $y } } stands for multi sub sumC(Int $x){ return {sub (Int $y){$x + $y }} } Again I added some more explaination in the text. Now that I've thought about it for 90 seconds (not fully-formed idea), if one were to have an anonymous multi-sub, it ought to be constructed from a list of /signature/, /body /pairs. And/or, any non-finalized sub could have a method to add another /signature, body/ to its dispatch list. Yes, or just as I proposed the list is the argument of the return. I think that the notation I proposed in the paper should not pose any problem to the parser (or the programmer). But as you said, I am out of topic here at least as long as this paper is concerned. my $sub = do { proto foo (|) { * } multi foo (Int $x) { $x + 1 } multi foo (Str $y) { $y ~ 'a' } foo; } Oh yes, nice ... I think I will add it in my paper (and if you send me your full name I will give credits to you) Thanks a lot, this is the kind of feedback I really was looking for. --Beppe---
Re: Types for Perl 6: request for comments
The anon does something. For example this code prints bob my $routine = proto bar (|) { * }; multi bar (Int $x) { $x - 2 } multi bar (Str $y) { $y ~ 'b' } say $routine('bo'); but change the first line to my $routine = anon proto bar (|) { * }; and you get an error Cannot call 'bar'; none of these signatures match: in block unit at type.p6:5 - and that makes sense to me, because anon means no name gets installed in any scope, and thus the multi bar declarations have nothing to hold on to. What confused me is that the $sub_anon example in my last email works, I expected it to give the same kind of error! It looks like adding the anon to the proto simply disconnects the proto from the multi, making it like there was no proto at all. -y
Re: Types for Perl 6: request for comments
Subs are lexical by default, so adding my to the function declarators does nothing. Not sure what anon is doing there. My guess is that anon in sink context does nothing, and Rakudo just builds another proto for foo when it sees the first multi. Protos are optional (but not in the compiler itself!), so that first line is redundant but good practice. On Sat, Jun 27, 2015 at 5:26 PM, yary not@gmail.com wrote: These two variations on Brent's work the same as the original- what subtle differences happen by adding anon or my to the declarations? my $sub_anon = do { anon proto foo (|) { * } multi foo (Int $x) { $x + 1 } multi foo (Str $y) { $y ~ 'a' } foo; } my $sub_my = do { my proto foo (|) { * } my multi foo (Int $x) { $x + 1 } my multi foo (Str $y) { $y ~ 'a' } foo; }
Re: Types for Perl 6: request for comments
I'm reading it a bit at a time on lunch break, thanks for sending it along, it's educational. My comments here are all about the example on the top of page 5, starting with the minutest. First a typo, it says subC where it should say sumC multi sub sumB is ambiguous, due to your use of ;; there. And sumI *should* be ambiguous, because the caller sumC(Int $x ;; $y) {sumI($x,$y)} means sumI will always be called with $x - Int and varying $y. That example could use a little re-working. Note to Rakudo-porters: Can the error message remember the ;; in the sig ? The message from Rakudo * has a , where the source has ;; which is misleading: Ambiguous call to 'sumB'; these signatures all match: :(Bool $y, Bool $x) :(Bool $y, Int $x) The comment example about considering anonymous multi definitions in the same block to define the same anonymous function does show the feature's desirability, but that proposed syntax might be problematic. (Deciding if how to make that part of the syntax is not in the scope of the paper, but since you brought it up) What if one wants to define two different anonymous multi subs in the same scope? A contrived example: sub pick_multi (Bool $p) { my multi sub hmmI(Int $y) { 2 * $y } my multi sub hmmI(Bool $y) { $y } my multi sub hmmB(Int $y) { 1 + $y } my multi sub hmmB(Bool $y) { ! $y } $p ?? hmmI !! hmmB } Yes, one could enclose each anon-multi-set in a do block, but it feels to me that defining an anonymous multi-sub should require a single statement, to avoid unintentional co-mingling within a block.