Front page | perl.perl5.porters |
Postings from August 2023
Re: PPC Elevator Pitch for Perl::Types
From:
Ovid
Date:
August 16, 2023 07:19
Subject:
Re: PPC Elevator Pitch for Perl::Types
Message ID:
CA+M4CHtMYzmUf2+thoBoCFNQ9=qEahE=Z6Jgz+n8iF2yhm7_EA@mail.gmail.com
Note: I accidentally sent this to Oodler directly, not CC'ing P5P.
On Wed, Aug 16, 2023 at 7:37â¯AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:
>
> Perl lacks sufficient exposure of the already-existing real natural
> Perl data types for use by the programmer. This has lead to false
> claims that the Perl interpreter "has no data types". This has
> also lead to countless programmer-hours spent devising synthetic
> or unnatural type systems that rely entirely on fuzzy data guessing
> via regular expressions, etc.
This looks an awful lot like an end-run around the Oshun discussion which I
had to close because some very simple, but important, questions were not
being answered. When I asked (
https://github.com/orgs/Perl-Oshun/discussions/27#discussioncomment-6581803)
a few questions about Will's "real types" approach, there was no response.
Yves (demerphq) got right to the point with pointing out that Will's
approach is extremely unlikely to work:
https://github.com/orgs/Perl-Oshun/discussions/27#discussioncomment-6680632
I finally closed that discussion after waiting two weeks for answers that
never came. So let me ask them again here, in hopes that *someone* who
knows the answers is willing to share them.
1. Can type failures be downgraded to warnings or disabled entirely?
When you're working with a multi-million line code base, having production
come crashing to a halt because your "integer" recieved 3.14 instead of 3
is going to get types ripped out quickly. Thus, this approach would likely
be of little use for existing systems.
2. Gradual typing?
(this was in my original email) *Your examples show types applied to all
variables. I can't find any that show types being gradually added one at a
time. Is that allowed, or is it all or nothing? If it's the latter, it's
completely useless for existing systems.*
(this is new for this email(: gradual typing might be allowed because I've
found an example in the RPerl documentation. I'm unsure if it applies to
Perl::Types, but I would assume it does. However, that makes question 3
even more important.
3. Do these types play well with others?
Per Yves' response, it's unlikely they will. Thus, the following would be
fatal:
my $var1 = 234;my integer $var2 = 456; # Perl::Typesmy $total
= $var1 + $var2;
Does the above work or not? If it doesn't, you've just locked out the
entire CPAN. If that's the case, can you please provide some
interoperability use cases?
I previously asked them in good faith and waited in vain for a response.
Now I'm asking them in exasperation.
Best,
Ovid
On Wed, Aug 16, 2023 at 7:37â¯AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:
> # Proposed Perl Changes Elevator Pitch for Perl::Types
>
> This document is the first step in the Proposed Perl Changes process:
>
> https://github.com/Perl/PPCs/blob/main/README.md
>
> Respectfully submitted by the _Perl::Types Committee_:
> * Will Braswell (WBRASWELL), Co-Founder & Chairman
> * Brett Estrade (OODLER), Co-Founder & 1st Vice Chairman
> * Zakariyya Mughal (ZMUGHAL), Co-Founder & 2nd Vice Chairman
> * John Napiorkowski (JJNAPIORK)
> * Darren Duncan (DUNCAND)
> * Nedzad Hrnjica (NHRNJICA)
> * Rohit Manjrekar (MANJREKAR)
> * Paul Millard (MAGUDAS)
> * Joshua Day (HAX)
> * Tyler Bird (BIRDTY)
> * Robbie Hatley (HATLEYSFT)
> * David Warner (WESTBASE)
> * Daniel Mera (DMERA)
> * Duong Vu (DVU)
> * Rajan Shah (RSHAH)
>
> ## Here is a problem
>
> Perl lacks sufficient exposure of the already-existing real natural
> Perl data types for use by the programmer. This has lead to false
> claims that the Perl interpreter "has no data types". This has
> also lead to countless programmer-hours spent devising synthetic
> or unnatural type systems that rely entirely on fuzzy data guessing
> via regular expressions, etc.
>
> Fortunately, the Perl compiler already provides the capability to
> expose the underlying real native C data types which can be used
> by Perl programmers to incrementally improve performance, eventually
> achieving the full native speed of compiled C code. Among other
> features, the Perl compiler also enables real natural data type
> checking with identical behavior in both dynamic (intrepreted) mode
> and static (compiled) mode.
>
> https://metacpan.org/dist/RPerl
>
> The data type subsystem of the Perl compiler is currently in the
> process of being extracted and refactored as an independant CPAN
> distribution called `Perl::Types`. This distribution provides new,
> core capabilities and thus should be included in the Perl core
> distribution as a "Dual-Life" module.
>
> https://github.com/Dual-Life
>
> ## Here is the syntax that we're proposing
>
> The Perl interpreter already has an unused slot in the grammar for
> this very purpose:
>
> `my TYPE $var;`
>
> The Perl interpreter and the Perl compiler already provide the
> basic data types to be used in the grammar slot above:
>
> * `boolean` (`SV` when `SvIsBOOL(sv)` is true, new in 5.36)
> * `integer` (`IV`)
> * `number` (`NV`)
> * `string` (`PV`)
> * `array` (`AV`) & `arrayref` (`RV(AV)`)
> * `hash` (`HV`) & `hashref` (`RV(HV)`)
> * user-defined classes
>
> Custom data structures are declared with compound or nested data
> types composed from the basic types above, for example:
>
> * `integer::arrayref`
> * `integer::arrayref::arrayref`
> * `integer::arrayref::hashref`
> * `integer::arrayref::arrayref::hashref`
> * `string::arrayref`
> * `MyClass::arrayref`
> * etc.
>
> Attempting to utilize incompatible data types gives the same behavior
> and same errors in both interpreted mode and compiled mode, for
> example:
>
> ```
> #!/usr/bin/perl
> use Perl::Types;
>
> sub squared {
> { my number $RETURN_TYPE };
> ( my number $base ) = @ARG;
> return $base ** 2;
> }
>
> squared(2); # FINE
> squared(2.3); # FINE
> squared(to_number('2')); # FINE
> my number $foo = 23;
> squared($foo); # FINE
>
> squared(); # ERROR ENVxx, TYPE-CHECKING MISMATCH: number value
> expected but ...
> squared('2'); # ERROR ENVxx, TYPE-CHECKING MISMATCH: number value
> expected but ...
> my string $bar = 'howdy';
> squared($bar); # ERROR ENVxx, TYPE-CHECKING MISMATCH: number value
> expected but ...
> squared([2]); # ERROR ENVxx, TYPE-CHECKING MISMATCH: number value
> expected but ...
> ```
>
> The syntax for arrays and hashes is similarly straightforward:
> ```
> sub multiply_array {
> { my number::arrayref $RETURN_TYPE };
> ( my integer $input_integer, my number::arrayref $input_array ) = @ARG;
> my number::arrayref $output_array = [
> $input_integer * $input_array->[0],
> $input_integer * $input_array->[1],
> $input_integer * $input_array->[2]
> ];
> return $output_array;
> }
>
> sub multiply_hash {
> { my number::hashref $RETURN_TYPE };
> ( my integer $input_integer, my number::hashref $input_hash ) = @ARG;
> my number::hashref $output_hash = {
> a => $input_integer * $input_hash->{a},
> b => $input_integer * $input_hash->{b},
> c => $input_integer * $input_hash->{c}
> };
> return $output_hash;
> }
> ```
>
> ## Here are the benefits of this
>
> The primary benefit of including `Perl::Types` in the Perl core
> distribution is that it will provide a greatly-needed capability
> of exposing the underlying C-level data types and data structures
> to every Perl programmer, so they may utilize Perl data types to
> achieve a number of benefits including but not limited to:
>
> * increased performance
> * code correctness
> * type safety (type checking)
> * memory safety (bounds checking)
> * documentation of code intent
> * potential for polymorphism
> * potential for derived or synthetic types
>
> Additionally, this foundational support for enabling Perl data
> types at the interpreter level will allow for the creation of
> synthetic or unnatural data types and data structures to be built
> on top of `Perl::Types` itself. For example, the capabilities
> provided in `Perl::Types` are necessary for any effort to introduce
> real natural type checking constraints related to Perl's new `class`
> keyword.
>
> ## Here are potential problems
>
> Because the Perl interpreter has already implemented both the real
> natural Perl data types, as well as the required `my TYPE $var`
> syntax construct, we therefore do not foresee the introduction of
> any significant issues by including `Perl::Types` in the Perl core
> distribution.
>
> The largest barrier to adoption for the Perl compiler is the need
> for numerous non-Perl dependencies, such as the C++ compiler and
> other libraries. This barrier will be completely removed for the
> `Perl::Types` distribution, due to being refactored out of the
> compiler distribution and removal of all non-core dependencies.
>
> On Behalf of the _Perl::Types Committee_,
> Brett Estrade
>
> --
> oodler@cpan.org
> oodler577@sdf-eu.org
> SDF-EU Public Access UNIX System - http://sdfeu.org
> irc.perl.org #openmp #pdl #native
>
--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/