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.
Types for Perl 6: request for comments
I wrote an article trying explain/propose (static) typing for Perl 6. In particular I explain how to type subs, multi subs, classes, multi methods; how to use union, intersection and subset types; and I finally use these notions to explain the old problem of covariance vs. contravariance in object-oriented programming. The target reader of (the first part of) the article is every Perl 6 programmer, which is why all the above is explained by examples of Perl 6 code (no formula, theory, theorem, or property whatsoever) and I tried to do my best to make the article completely self-contained. This is also why comments from this mailing list are *very* welcome. The second part of the paper targets language implementers and designers: if the first part convinced you of the usefulness of such (possibly optional) types, then you will find in the second part the details of data structures and algorithms to efficiently implement this type system. I also give extensive references in which you will find how to extend the system by some missing bits (notably, polymorphism). The paper can be retrieved at the following url. http://www.pps.univ-paris-diderot.fr/~gc/papers/perl6-typing.pdf I insist, comments from Perl 6 programmers will be extremely welcome: just do not be (too) harsh, please :-) Thank you in advance for your help Giuseppe Castagna
