Front page | perl.perl5.porters |
Postings from August 2023
Re: PPC Elevator Pitch for Perl::Types
Thread Previous
|
Thread Next
From:
Leon Timmermans
Date:
August 19, 2023 08:40
Subject:
Re: PPC Elevator Pitch for Perl::Types
Message ID:
CAHhgV8it3JO8Aq9Dqo68pkh0gFaUMzVowC8GoRmHVSUjmopnJQ@mail.gmail.com
On Sat, Aug 19, 2023 at 4:56â¯AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:
> > In what circumstances are these type checks carried out / enforced? Is it
> > just on scalar and list assignment? Or more generally? For example, does
> > this croak?
>
> > sub mutate { $_[0] = 'foo' }
> > my number $x;
> > mutate($x);
>
> The Perl compiler currently supports type enforcement for subroutine
> calls, so that is our starting point for Perl::Types. Thus, your
> example above would not croak, because the subroutine does not
> specify any data types for its input arguments. Type checking is
> simply disabled for subroutines without input argument types.
>
> If you added `( my number $my_arg ) = @ARG;` to the top of your
> `mutate()` subroutine, then yes it would croak with a complaint
> `... number value expected but undefined/null value found ...`
> because you never assigned a value to `$x`. This is achieved by
> inserting calls to the appropriate type-checking C macros or
> functions for each typed input argument, inserted immediately
> following the `@ARG` statement. So for your `mutate()` subroutine,
> Perl::Types would automatically call either the `number_CHECK()`
> or `number_CHECKTRACE()` macro on the value received into `$my_arg`,
> which is where the croaking occurs:
>
>
> https://metacpan.org/release/WBRASWELL/RPerl-7.000000/source/lib/RPerl/DataType/Number.h#L137-149
>
> ```c
> // [[[ TYPE-CHECKING MACROS ]]]
> #define number_CHECK(possible_number) \
> (not(SvOK(possible_number)) ? \
> croak("\nERROR ENV00, TYPE-CHECKING MISMATCH,
> CPPOPS_PERLTYPES & CPPOPS_CPPTYPES:\nnumber value expected but
> undefined/null value found,\ncroaking") : \
> (not(SvNOKp(possible_number) ||
> SvIOKp(possible_number)) ? \
> croak("\nERROR ENV01,
> TYPE-CHECKING MISMATCH, CPPOPS_PERLTYPES & CPPOPS_CPPTYPES:\nnumber value
> expected but non-number value found,\ncroaking") : \
> (void)0))
> #define number_CHECKTRACE(possible_number, variable_name, subroutine_name)
> \
> (not(SvOK(possible_number)) ? \
> croak("\nERROR ENV00, TYPE-CHECKING MISMATCH,
> CPPOPS_PERLTYPES & CPPOPS_CPPTYPES:\nnumber value expected but
> undefined/null value found,\nin variable %s from subroutine %s,\ncroaking",
> variable_name, subroutine_name) : \
> (not(SvNOKp(possible_number) ||
> SvIOKp(possible_number)) ? \
> croak("\nERROR ENV01,
> TYPE-CHECKING MISMATCH, CPPOPS_PERLTYPES & CPPOPS_CPPTYPES:\nnumber value
> expected but non-number value found,\nin variable %s from subroutine
> %s,\ncroaking", variable_name, subroutine_name) : \
> (void)0))
> ```
>
> > Speaking as a perl internals expert, can you explain to me in general
> > terms how Perl::Types does its thing?
>
> As you can see in the C macros above, we are exposing the real
> native Perl data types by directly accessing the `SvOK()`, `SvIOKp()`,
> and `SvNOKp()` internals. Perl::Types is not inventing its own
> definition of types, it is only exposing the already-existing real
> native Perl data types such as `IV`, `NV`, `PV`, etc. Real native
> Perl data structures can likewise be exposed by way of the `AV`
> and `HV` Perl data types, by directly accessing `SvAROKp()` and
> `SvHROKp()`:
And all of that is entirely wrong. Scalars have a has-a relationship with
IV/NV/PV/RV (with only two of them being mutually exclusive with each
other), and looking at it the right/wrong way can change three of these.
Your concept of a value being a number or not is entirely fictional.
Leon
Thread Previous
|
Thread Next