Re: Pre-PPC: native data checks for Perl

[Darren Duncan]

It comes across to me that the vast majority of those who commented on this
proposal feel that NAME CHECK order is strongly preferred over CHECK NAME order,
for a number of both pragmatic and aesthetic reasons, plus similarity with a
subset of other languages, plus its what the Oshun proof of concept currently does.

While it comes across to me that the only arguments for CHECK NAME order is that
it is similar to a different subset of other languages and that the Perl parser
already implements it to a degree as an unrealized feature.

Given this, I feel that using NAME CHECK order for Oshun seems to be the clear
winner to go with; while not unanimous it has a very clear strong lead.

-- Darren Duncan

On 2024-01-05 11:35 p.m., James Watson wrote:
> On 5 Jan 2024, at 03:55, Paul "LeoNerd" Evans <leo...@leonerd.org.uk> wrote:
>> Actually the more I think on this, the more I think that actually
>> putting a constraint name /after/ the thing that is being constrained
>> makes more sense. It's extra useful information that doesn't get in the
>> way upfront understanding of the thing. So maybe constraint checks come
>> afterwards:
>>
>> sub fibonacci($nth PositiveInt) UINT
>> {
>> ...
>> }
>>
>> It means as a human reader you can kindof ignore all those bits and
>> skim over them, and they don't get too much in the way.
>>
>> sub fibonacci($nth ##--------) ##--
>> { ... }
>
> +1 from me. Even in languages that arrange these elements differently, this is how my monkey brain parses the information.

[Martijn Lievaart via perl5-porters]

Op 07-01-2024 om 22:47 schreef Lukas Mai:
> On 07.01.24 21:19, Martijn Lievaart via perl5-porters wrote:
>>
>>
>> I may be wrong, but doesn't this depend on the check itself? If the
>> check implements deep checking, it implements deep checking, if it
>> doesn't, it doesn't. Which is just a part of the contract. So I would
>> say contract is fine, and I think preferable.
>
> Consider this case:
>
>     my @array = (1, 2, 3);
>     my $ref :ArrayRef(Int) = \@array;  # presumably OK
>     $array[0] = "hello";  # validate here??
>     say $ref->[0];  # not an integer anymore??
>
> If you start modifying structures that are referenced from elsewhere
> (arbitrarily deeply), you can't easily find all the "checked" places
> from which a particular scalar is reachable (in order to re-run all
> their checks) and it would be slow. So even if a check implements deep
> checking, that only saves you if the check is actually triggered and
> gets to run, which it probably won't if inner structures are also
> reachable through a non-checked path.


That's not the point I tried to make. The issue is, is the name
'contract' appropriate even if checks aren't deep. Which I tried to
argue, it is.


HTH,

M4