Front page | perl.perl5.porters |
Postings from August 2023
On Wed, Aug 16, 2023 at 6: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: > Frankly, this is all unworkable. Perl has a very simple type system[1]. Imagining non-existent types to exist isn't helpful. You may be able to create a system of checks on assignment/passing, but that's a different thing entirely from those values having these types. Given that anything can have references, those checks can't truly provide invariants. This is not a type system. Leon 1: https://twitter.com/leon_timmermans/status/1659557093110587394Thread Previous | Thread Next