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 cut&paste 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,$y>0) }

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---