90 likes | 182 Views
Perl has $#@% For Types. Or, Strengthening Perl’s Type System by Brian Clarke. Philosophy.
E N D
Perl has $#@% For Types Or, Strengthening Perl’s Type System by Brian Clarke
Philosophy • ”[Perl] doesn't try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn't have any theoretical axes to grind. And where it has theoretical axes, it doesn't grind them. Perl doesn't have any agenda at all, other than to be maximally useful to the maximal number of people. To be the duct tape of the Internet, and of everything else.” --Larry Wall • “Since you gave Perl a ridiculous request, Perl dutifully provides you in return a ridiculous response--but not an error; oh no, not that!” --Tom Christiansen
Fundamental Perl Types • Scalars • use $ • SCALAR := { integer U double U string U REFERENCE } • REFERENCE := scalar_reference | array_reference | hash_reference | REFERENCE • Arrays • lists of SCALAR • Hashes • mapping of { string -> SCALAR }
Contexts and Coercions • Thingys in Perl are evaluated in terms of the context in which they are used • scalar (void, boolean, string, number,…) • list (list of scalars) • Can have some *interesting* results • What is an array in scalar context? • Even better: what is a hash in scalar context?
use strict ‘types’; • Stricter definitions and contextual rules • enhanced compile-time and run-time checking • type information must be visible, and stored • necessitates additional syntax/keywords • integer, double, string, *ref, typed_sub, etc. • internal representation must facilitate this • interpreter already has a type bitmask • add support to other types • all types could be objects internally…future work • type check subroutine parameters
Oh, wait, you’re serious?! • YES. • “There’s More Than One Way To Do It”, so why not one more? • Interpreter has initial framework, at least for storing type information • coercion rule set would be reduced • my Dog $spot;
Perl6 RFCs • Several RFCs discuss/mention some of the ideas of this project (often very informally) • Everything in Perl becomes an object (RFC 161), All Perl core functions should return objects (RFC 73) • Stronger typing through tie (RFC 15) • Types and structures (RFC 122) • Subroutine prototypes and parameters (RFC 57)
Is it really useful? • More readable code • Easier to reason about behavior • human reading • compiler and runtime checking • More efficient code produced for backend • other VMs being targeted, compile-time type knowledge will help
Conclusions • Project meets evaluation criteria • Perl6 will probably see a number of these (or similar) ideas implemented • Perl will remain Perl: • everything for everyone • One More Way To Do It • nothing unPerlish about it