Native data checking in Perl

Front page | perl.perl5.porters | Postings from May 2023

Native data checking in Perl

Thread Next

From:

Ovid

Date:

May 17, 2023 08:18

Subject:

Native data checking in Perl

Message ID:

CA+M4CHsPnufh_Q35B7qz+ch52nEyt2zMSucTPrKx1nvPXcszwA@mail.gmail.com

Hi all,

Iâve been reading through past P5P messages to get a better sense of what
the porters are willing to accept for declaring âtypes.â Iâll use the term
data âchecksâ to avoid confusion about type systems.

For a few months, Damian and I have been hashing out a system of checks for
Perl. In particular, we looked at some of the most popular solutions:
Moo/se and Type::Tiny (working within Perlâs constraints), and also Dios an
Zydeco (working to extend Perlâs constraints), plus Raku and some
diversions into other languages.

Unfortunately, Damian deeply regrets that, for personal reasons, he is
unable to continue to work on the project, but is still wholeheartedly in
favor of its stated goals.

At present, thereâs a working implementation in a private repo and we
support things like this:

    sub foo :returns(ARRAY[INT]) ( $max_size :of(UINT) ) {...}
    my $count :of(INT) = 0;

In fact, we support a lot more than that and have almost 200K tests
passing, though it's still very much alpha.

In reading P5P and other discussions, it was pleasant to see that thereâs
little objection to the notion of checks, but the disagreements largely
arise over syntax and then discussion dies down again. In sharing our work
privately with others, the strongest objection has been the syntax. People
want this (punting on return values):

    sub foo ( UInt $max_size ) returns ArrayRef[Int] {...}
    my Int $count = 0;

Or this:

    sub foo ( $max_size is Uint ) returns ArrayRef[Int] {...}
    my $count is Int = 0;

Or something else entirely.

Our proposal used attributes simply because we were concerned that P5P
would reject the my Dog $spot syntax (and I like the attribute syntax)
because itâs already taken (though not frequently used). However, given the
feedback, I think this didnât need to be a concern.

Can we discuss this? I think the *semantics* are largely in place. Itâs the
*syntax* where things keep breaking down. If we can find an agreed syntax,
I can take the existing work and write up a spec (thatâs actually the hard
part, but most of itâs done, pending syntax changes).

The design âthe thing and hand it overâ worked for Corinna. This will be a
much more important change, but it can work here, too.

Best,
Ovid

Thread Next