develooper Front page | perl.perl5.porters | Postings from August 2023

Re: PPC Elevator Pitch for Perl::Types

Thread Previous | Thread Next
From:
Martijn Lievaart via perl5-porters
Date:
August 21, 2023 10:30
Subject:
Re: PPC Elevator Pitch for Perl::Types
Message ID:
ef77fdfe-77b0-da0d-9500-a8b672c23ac2@rtij.nl
Op 21-08-2023 om 11:21 schreef Chris Prather:
> On Mon, Aug 21, 2023 at 2:38 AM Martijn Lievaart via perl5-porters
> <perl5-porters@perl.org> wrote:
>> [...] But I may miss something obvious, or something very deep. So can anyone explain why Perl::Types can work at all, and what changes to the implementation of the language are needed for that?
> For anything like Perl::Types to work in we're going to at a minimum
> need to expand type annotation support, especially around subroutine
> signatures.
>
> Any Type system is going to want three things:
>
> 1) A way to annotate code with the types (e.g. `my Dog $fido`)
> 2) A way to assert the type (e.g. `my Dog $fido = Cat->new(); # dies
> because Cats aren't Dogs `)
> 3) A way to define new types (e.g. `type Dog { $_ isa Dog }`)
>
> #3 depends on #2 and #1, with Perl::Types you can just create a class
> … how that mechanism works outside of RPerl is currently undefined. In
> theory #2 is taken care of if all they're doing is exposing the
> underlying SV subtypes. In practice people are arguing that's a
> nonsensical thing to do, and ultimately there may need to be some work
> there (there definitely is for Oshun style checks).


So basically you are implying #2 can work for classes (for Perl::Types), 
because classes use SVs in a certain predictable way. But for anything 
else, this will not work as exposing SVs will not do anything useful for 
the context we are looking at, correct?


> #1 however can't work without better support from Perl guts because
> the mechanism that Perl::Types is currently using[1] will, as best
> I've seen, only work on scalars (`my Child @children` doesn't trigger)
> and will only work with explicit syntax like `(my Dog $fido, my Cat
> $kitty) = @_` which is IMO painful enough I'd avoid using it. There is
> also no support (yet) for subroutine signatures `sub (Dog $fido, Cat
> $kitty, Child @children) { ... }`.[2]


That more or less sounds like it is doable, so no big problems there 
(although performance impact remains to be seen, obviously).


M4


> [2] You can currently annotate a return type using a subroutine
> attribute `sub adopt :returns(Dog) ($id) { ... }`. Implementing #2 on
> subroutines is left as a lemma for the reader.


:P



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About