Document Sample
clarke Powered By Docstoc
					Perl has $#@% For Types

  Or, Strengthening Perl’s Type
           Brian Clarke
   ”[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 := 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
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
    – other VMs being targeted, compile-time
      type knowledge will help

   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

Shared By: