Mailing List Archive

More on adding data checks in Perl
Hi all,

It seems like we're getting closer to consensus, but aren't quite there
yet. Admittedly, my desire to avoid discussing semantics has failed because
sometimes you *must* consider them, but please let's not bring up semantics
unless it's absolutely necessary. We're very close to being able to put
together a proposal here. I promise I'll follow-up with semantics later,
but probably on a github repo rather than on P5P (though I'll drop a link
here).

One glaring issue with the design of the data checks is this:

my @grades :of(HASH[HASH[INT]]);

There have been some previous, private discussions about this which revolve
around the SHOUTY nature of the check names. They're contentious, but there
are reasons for them. First, `perldoc -f ref` has this:

If the unblessed referent is not a scalar, then the return value
will be one of the strings "ARRAY", "HASH", "CODE",
"FORMAT", or "IO", ... and so on

So we're trying to mostly match the names to what `ref` returns,
though obviously INT, STR, NUM, and friends don't quite fit.

Second, we have this Fahrenheit to Celsius sub:

sub f_to_c ($f :of(NUM)) :returns(NUM) {...}

f_to_c(32) returns 0. f_to_c(-1000) returns -573.333333333333.

However, that doesn't really make sense, since that's below absolute zero.
So we have this:

check Celsius :isa(NUM[-273.14..inf]);
check Fahrenheit :isa(NUM[?459.67..inf]);

Which gives us a much safer, and self-documenting signature:

sub f_to_c ($f :of(Fahrenheit) :returns(Celsius) {...}

If you have an error in your user check definition, you can fix it one
place and it works everywhere. But honestly, there are plenty of times
where adding a custom check to a one-off definition is overkill. So we
allow my $count :of(INT) = 0;,

In other words, the SHOUTY version of the check names is a subtle
disaffordance against using the built-in checks since, semantically, they
don't tell us much, but you can still use them.

Another reason is that a user-defined check would be required to have at
least one lower-case letter in the name, making it possible to immediately
distinguish them from built checks.

We could be a touch more live Java and have built-ins lower-case and
require leading upper-case for user-defined. That increases the likelihood
that we'll have parsing issues if we encounter a check that matches a
keyword or a subroutine name. This problem is pretty much non-existent if
we use attributes. However, while my int $count = 0; isn't a big deal,
other uses are more complex. What's the syntax for returning checked values
from subs? Branislav would like to apply checks to expressions, not just
variables. If we want that, how would that work? These are certainly cases
where semantics and syntax overlap.

Best,
Ovid
Re: More on adding data checks in Perl [ In reply to ]
On Sun, 21 May 2023 11:07:51 +0200
Ovid <curtis.poe@gmail.com> wrote:

> Hi all,
>
> It seems like we're getting closer to consensus, but aren't quite
> there yet. Admittedly, my desire to avoid discussing semantics has
> failed because sometimes you *must* consider them, but please let's
> not bring up semantics unless it's absolutely necessary. We're very
> close to being able to put together a proposal here. I promise I'll
> follow-up with semantics later, but probably on a github repo rather
> than on P5P (though I'll drop a link here).

I haven't been replying or even reading yet because I'm super-busy
getting ready for my stage show next week, but I'm sure I'd have lots
of interest and ideas here. Give me a couple of weeks to have a good
look over first.

One thing though is that surely we can't discuss purely syntax without
considering what semantics the syntax is supposed to do? That way seems
madness. In fact surely it's better to decide what *behaviours* we want
to add, and then after that's all agreed work out how we want the
syntax to look in order to request them. It seems very strange to be
discussing syntax for an as-yet-handwavy idea of behaviour.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: More on adding data checks in Perl [ In reply to ]
On Sun, May 21, 2023 at 3:59?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:


> > Hi all,
> I haven't been replying or even reading yet because I'm super-busy
> getting ready for my stage show next week ...


Good luck with the stage show!

One thing though is that surely we can't discuss purely syntax without
> considering what semantics the syntax is supposed to do? That way seems
> madness. In fact surely it's better to decide what *behaviours* we want
> to add, and then after that's all agreed work out how we want the
> syntax to look in order to request them. It seems very strange to be
> discussing syntax for an as-yet-handwavy idea of behaviour.


It's certainly a bit of a chicken-and-egg problem. I punted on semantics
(though they're moderately well defined in the spec that's created) because
the objections from various private conversations seems to be almost
entirely over syntax. Thus, I was hoping to deal with the main issue people
have. I'll try to write up some brief discussion over semantics. Some of
that will be problematic because, yes, it's intertwined with syntax.

Best,
Ovid
Re: More on adding data checks in Perl [ In reply to ]
On May 21, 2023, at 10:33 AM, Ovid <curtis.poe@gmail.com> wrote:

?On Sun, May 21, 2023 at 3:59?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
> Hi all,
I haven't been replying or even reading yet because I'm super-busy
getting ready for my stage show next week ...
Good luck with the stage show!


Definitely break a leg!
It's certainly a bit of a chicken-and-egg problem. I punted on semantics (though they're moderately well defined in the spec that's created) because the objections from various private conversations seems to be almost entirely over syntax. Thus, I was hoping to deal with the main issue people have. I'll try to write up some brief discussion over semantics. Some of that will be problematic because, yes, it's intertwined with syntax.


I’m not sure you linked to the spec anywhere, so yeah I think part of this may be arguing over in a void you don’t personally have because other people don’t have the spec in front of them.
- Chris
Re: More on adding data checks in Perl [ In reply to ]
On Sun, May 21, 2023 at 4:56?PM Chris Prather <chris@prather.org> wrote:


> I’m not sure you linked to the spec anywhere, so yeah I think part of this
> may be arguing over in a void you don’t personally have because other
> people don’t have the spec in front of them.
>

OK, I give. Damian is brilliant, but not concise. I may not be concise, but
what I had planned to share was shorter than what Damian wrote. You'll see
that in the link at the bottom.

The link contains a "public" version of the result of months of us working
out what was needed. But it's actually based on years of experience. For
him, being a computer scientist, having designed several type systems, and
seeing what is actually implemented and accepted in Perl.

For me, it's years of experience seeing what is actually implemented and
accepted in Perl, trying my hand at designing something (I failed), reading
a lot about the topic, and seeing the trainwrecks inside of companies when
good intentions meet reality (for example, trying to be too "strict" in the
face of Perl).

We eventually came to a compromise that gave neither of us what we wanted,
but definitely seemed much closer to what was feasible. The biggest issue,
in those we talked to (they can out themselves if they want and are here),
was the syntax, not the semantics. Hence, my trying (in error, apparently),
to focus on that.

Many people learn better from the theory and *then* the examples. Others
learn better from examples and *then* the theory. I'm one of the latter.
Damian's apparently one of the former. It made collaboration better.

My intent was to write the examples and then present the theory for those
who wanted to go further. Instead, you get Damian. So here's the doc:
https://gist.github.com/thoughtstream/08b7fd48b09c99ae47d6d9f82b913986

Best,
Ovid