Here's a summary of the points that came up in Larry's Atlanta Linux
Showcase talk.  I've run this summary past Larry, and he has approved
it as being a fair representation of what he said.  Remember that
these are just his current thoughts, not concrete decisions.

This is available on the web through a link at http://dev.perl.org/,
along with the full text and a link to mp3s.

Nat

  * He's dividing Perl community's suggestions (the RFCs) into Good, Bad,
    and Ugly.  Ranking each according to the importance of the problem
    being solved, and the quality of the solution.  Some RFCs have
    identified important problems, but their proposed solutions will
    need to be replaced with more Perlish forms.

  * Perl's parser and lexer will be written in Perl, using Perl regular
    expressions.  That's us eating our own dogfood, or whatever the
    phrase is.

  * The language will be dynamically extensible, using modules written
    in Perl.  So you can program in a language that looks like Python,
    Latin, or Java, if you want.  In this sense, the Perl compiler and
    runtime system become a meta-language (extra-lingual?) system that
    lets you code in your own favourite little (or large) language.
    Perl would just be one of the languages you could implement.

  * The flip-side of this is little languages: make it easy for folks
    to have their own domain-specific "little" language.  Make Perl a
    environment for building domain-specific languages.

  * The Perl compiler and interpreter systems will be designed so that
    they can emit C, Java, and C# code.  This doesn't mean that perl6
    will ship with all three back-ends, but they will be easy to
    implement.

  * "Non-critical built-ins", for example sockets and operating system
    calls, will no longer be operations in the core of Perl.  They'll
    be in dynamically loaded, possibly automatically loaded, modules.

  * Variables will be treatable as objects.  Under the hood we'll use
    a vtable system, a little like that of C++ but dynamically
    changable.

  * Special global variables will be replaced with more appropriate
    and lexically-scoped alternatives.  Some of them will be attached
    to filehandle objects instead.

  * Typeglobs will go away.

  * XS, the system for extending Perl with C or C++, will be replaced
    with something much easier to use.  This will give people very
    convenient access to existing code libraries, and write C or C++
    subroutines that can be called as Perl subroutines from Perl code
    to take advantage of C's speed and memory flexibility.

  * Perl will permit function and method signatures (prototypes) to
    enable certain compile-time optimizations and checks.  These will
    not be mandatory, but if someone wants compile-time type checking
    then they can have it.

  * Completely object-oriented exception handling, with a simple
    string-like interface for those who do not want the power of the
    full OO system.

  * True and false in Perl are used to mean "interesting" and
    "uninteresting".  Overloadable logic operators are a possibility,
    to let you decide what is interesting and uninteresting in your
    world.

  * Perl will support many types of low-level programming, letting you
    specify types for variables, homogeneous arrays, compact arrays,
    and more.

  * Perl will also support many types of high-level programming,
    adding more support for functional programming (the reduce operator),
    logic programming (???), and the little languages.

  * There won't be default-loaded site configuration files.  Implicitly
    loaded code is a recipe for un-portable un-debuggable confusion.

  * Add the ability to declare lexically-scoped Unicode operators for
    mathematicians.  If they want to apply the rho function to sigma,
    then they can.  If they want to map the Arabic letter Farsi "yeh"
    to the scalar Thai character "tho nangmontho" then they can do
    that too.


Reply via email to