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