Frequently Asked Questions

[Ovid]

This project has started off in "stealth" mode, which meant a private repo. However, that means we don't get wikis unless I upgrade or convert to a public repo. Because we can't go public yet, some information that should be in a wiki is going here for right now.

For first-person references (e.g., "I am" or "I think"), assume that the person is Ovid, the author of this FAQ.

Isn't this a type system?

"Data checks," not "types."

Computer scientists have reasonable disagreements over what they want in a type system.

Computer programmers have screaming matches.

We are doing an end-run around the screaming matches. The term "type" is so heavily overloaded that it's often meaningless. Further, if we say "type system," many people want something different out of it. In fact, Data::Checks doesn't do what I want out of it. However, we have tried to find a reasonable compromise based on popular CPAN modules (in particular, Type::Tiny and Moo/se) in this area and making something that feels "Perlish."

So we don't use the word "type." These are declarative data checks.

Are data checks going into the Perl core?

We hope so. We don't know what the syntax would look like, but we see general support for the idea both in the Perl community and P5P itself. We cannot make any guarantees. However, P5P often wants a CPAN module first, just to see if an idea is sound. This is very valuable, so we created Data::Checks.

I don't need data checks, so why add them?

You're right. Your code often doesn't need data checks. However, when we start collaborating, different teams might have different expectations and you don't know who is calling your code or how they are using it. Data checks become extremely valuable when we're dealing with the boundaries between your code and theirs.

Why my $foo :of(INT) instead of my INT $foo?

Via perldoc -f my:

my VARLIST
my TYPE VARLIST
my VARLIST : ATTRS
my TYPE VARLIST : ATTRS

A "my" declares the listed variables to be local (lexically) to the enclosing block,
file, or "eval".  If more than one variable is listed, the list must be placed in 
parentheses.

The exact semantics and interface of TYPE and ATTRS are still evolving.  TYPE
may be a bareword, a constant declared with "use constant", or "__PACKAGE__".
It is currently bound to the use of the fields pragma, and attributes are handled
using the attributes pragma, or starting from Perl 5.8.0 also via the Attribute::Handlers
module.  See "Private Variables via my()" in perlsub for details.

Note that with a parenthesized list, undef" can be used as a dummy placeholder,
for example to skip assignment of initial values:

    my ( undef, $min, $hour ) = localtime;

In other words, my Dog $spot is existing, valid syntax in Perl, though it doesn't do much. However, P5P is loathe to risk breaking existing code. We think reusing this syntax is mostly safe since it would be lexically scoped, but out of an abundance of caution, we have decided to use my $spot :of(Dog) to avoid the the inevitable "backwards-compatibility" argument. Plus, we have no idea what the darkpan is possibly doing this with this syntax.

We fully admit that this might be a mistake. However, we see from languages like Go that there's precedent for declaring the type after the variable identifier:

var x, y int = 3, 4

Why did this project start in stealth mode?

It wasn't clear if it would work. There was no desire to get people's hopes up if we couldn't pull this off.

Why are the checks SHOUTY?

These are the built-in checks:

my $total_legacy :of(UINT) = 0;
foreach my $customer (@customers) {
    $total_legacy += 1 if $customer->is_legacy;
}

But what about this?

sub celsius_to_fahrenheit :returns(NUM) ($celsius :of(NUM)) {
    return 32 + (9/5) * $celsius;
}

sub fahrenheit_to_celsius :returns(NUM) ($fahrenheit :of(NUM)) {
    return ($fahrenheit - 32) * (5/9);
}

But what if, one day, you discover celsius_to_fahrenheit returning -500? In reality, 459.67 is the lowest possible Fahrenheit temperature. That means you must have passed in a celsius temperature less than −273.15.

You could go through everywhere and write code to check that the values are sane ... or you could create your own data checks which throw exceptions on invalid values and then everything which has those data checks automatically does the right thing.

sub celsius_to_fahrenheit :returns(Fahrenheit) ($celsius :of(Celsius)) {
    return 32 + (9/5) * $celsius;
}

sub fahrenheit_to_celsius :returns(Celsius) ($fahrenheit :of(Fahrenheit)) {
    return ($fahrenheit - 32) * (5/9);
}

In the above, the user-defined checks means you don't have to write any code to get the data protection you're looking for. Further, the fact that they're not "all caps" tells the developer they can actually fix the checks if they turn out to not be correct.

That being said, as of this writing, we have not yet implemented user-defined checks.

Why is my $offset :of(INT); fatal?

In Perl, it's common to write something like this:

my $offset;

if ($condition) {
    $offset = get_offset();
}

if (defined $offset) {
    ... do something
}

However, with data checks:

my $offset :of(Int); # fatal error

That's because an undeclared variable has a value of undef and that violates the check constraint. Since Perl makes no distinction between "undefined" and "undeclared," it's not easy to fix. You could do this:

my $offset :of(INT | UNDEF);

That "fixes" the issue, but it's a bit of a hack. Doing the following is probably safer:

my $offset :of(INT) = 0;

As with any new language or paradigm, you need to learn new best practices.

Note that my @offset :of(INT); and my %offset :of(INT); are not fatal because an empty array or hashref can satisfy the check. Collections of scalars can be empty. It's when a scalar itself exists that the check must be applied.

How did this come about?

In December of 2022, I posted a gist about data types in Perl. There was positive reaction, as there often is when optional data checks for Perl are discussed. However, I've seen many of these conversations and while support for the idea is generally there, everything breaks down over the syntax and semantics.

One things led to another and Damian Conway and I started having a long conversation about data checks and what the design should be. There was a lot of back and forth and the design evolved considerably. Neither of us got exactly what we wanted, but for something this important, compromise is needed. Eventually, Damian created a prototype.

Why is Damian no longer on the project?

Damian deeply regrets that, for personal reasons, he is unable to continue to work on the project, but is still wholeheartedly in favour of its stated goals and wishes the new team every success. And that he'll also be happy to answer any questions about his work to date...as and when his now-extremely-limited free time permits.