Hi all (directly copying Dave as this could impact his signature work),
This might seem premature give that Perl 7 is still being actively discussed, but I'm hitting a stumbling block in Cor's design regarding types. (I assume types cannot be implemented in the first release unless we steal from Types::Standard and friends). For quite some time, I've had things like this in my examples:
has $foo :isa(Int);
However, I know that Dave Mitchell is working on signatures and he's looking at types too. If we have types in signatures and types in Cor, we're eventually going to get to the point of someone expecting this to work:
my $foo :isa(Int);
In other words, Perl will support gradual typing with all of the lovely safety that so many of us crave (or maybe just I do?)
However, we have both syntax and semantic issues. Dave's proposal (https://www.nntp.perl.org/group/perl.perl5.porters/2019/11/msg256683.html) looks very clear and, given that it predates Cor, it's not surprising that his syntax is different from Cor's syntax. If Perl is going to have types, we do not want different syntax for signatures, variable declarations, and class slot declarations.
The reason Cor uses attributes is because the has declarator, unlike in Moo/se, only declares the instance variable. It does nothing else. All other behaviors are provided via attributes and those attributes are almost fully composable (I've tried hard to decouple everything). For example, a 2D Point class that allows you to read and write the x/y data looks like this:
class Point {
has ( $x, $y ) :reader :writer :new :isa(Num);
method invert () {
return Point->new( x => $y, y => $x );
}
}
Attributes are very familiar to Perl developers and it seemed an easy way to extend things. Going with Dave's proposal, I'd have to do this:
has ( $x, $y ) :reader :writer :new is Num;
I find that a touch jarring, but I could live with it. Whatever syntax we go with, it needs to be nailed down so design work can continue.
That brings me to semantics.
I've been doing a moderate amount of reading about type systems and one thing that stands out is that bolting type systems onto languages without "traditional" type systems is hard. While I've opened a ticket about this, I think it would be particularly helpful if people were to read a follow-up comment about what types would mean in Perl. The summary: Perl's behavior, absent types, should not change. Perl's behavior, with types, should provide a sound type system and not try to emulate Perl's behavior. (you can throw rotten tomatoes at me now).
I know very little of Perl's internals or what this would mean. For Cor V1, I'd be tempted to go with attributes and Types::Standard (:isa(ArrayRef[Int])), but I strongly suspect that it will conflict with David's work, and it won't provide the type safety one would expect.
If there are strong counter-arguments, I'd be delighted to say I was wrong.
Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
This might seem premature give that Perl 7 is still being actively discussed, but I'm hitting a stumbling block in Cor's design regarding types. (I assume types cannot be implemented in the first release unless we steal from Types::Standard and friends). For quite some time, I've had things like this in my examples:
has $foo :isa(Int);
However, I know that Dave Mitchell is working on signatures and he's looking at types too. If we have types in signatures and types in Cor, we're eventually going to get to the point of someone expecting this to work:
my $foo :isa(Int);
In other words, Perl will support gradual typing with all of the lovely safety that so many of us crave (or maybe just I do?)
However, we have both syntax and semantic issues. Dave's proposal (https://www.nntp.perl.org/group/perl.perl5.porters/2019/11/msg256683.html) looks very clear and, given that it predates Cor, it's not surprising that his syntax is different from Cor's syntax. If Perl is going to have types, we do not want different syntax for signatures, variable declarations, and class slot declarations.
The reason Cor uses attributes is because the has declarator, unlike in Moo/se, only declares the instance variable. It does nothing else. All other behaviors are provided via attributes and those attributes are almost fully composable (I've tried hard to decouple everything). For example, a 2D Point class that allows you to read and write the x/y data looks like this:
class Point {
has ( $x, $y ) :reader :writer :new :isa(Num);
method invert () {
return Point->new( x => $y, y => $x );
}
}
Attributes are very familiar to Perl developers and it seemed an easy way to extend things. Going with Dave's proposal, I'd have to do this:
has ( $x, $y ) :reader :writer :new is Num;
I find that a touch jarring, but I could live with it. Whatever syntax we go with, it needs to be nailed down so design work can continue.
That brings me to semantics.
I've been doing a moderate amount of reading about type systems and one thing that stands out is that bolting type systems onto languages without "traditional" type systems is hard. While I've opened a ticket about this, I think it would be particularly helpful if people were to read a follow-up comment about what types would mean in Perl. The summary: Perl's behavior, absent types, should not change. Perl's behavior, with types, should provide a sound type system and not try to emulate Perl's behavior. (you can throw rotten tomatoes at me now).
I know very little of Perl's internals or what this would mean. For Cor V1, I'd be tempted to go with attributes and Types::Standard (:isa(ArrayRef[Int])), but I strongly suspect that it will conflict with David's work, and it won't provide the type safety one would expect.
If there are strong counter-arguments, I'd be delighted to say I was wrong.
Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl