http://www.perlmonks.org?node_id=563079


in reply to The Perl Hacker Inferiority Complex

To me, Perl 6 is like a director's cut of CPAN. From the RFC process till today, each part of Perl 6 feature either came from, or has been realized, as CPAN modules. (cf. the v6.pm stack diagram -- much more modules are present in each layer than shown there.)

During the making of Perl 6, what we are doing can be seen as: Take those Perl 5 extensions, which are all nice tools that solves real problems, present them as the default, and make them play well with each other.

Of course, the "play well" part involves a lot of work. However, one thing I like about the v6.pm path is it's gradual and completely opt-in. If you are interested only in some part of Perl 6, use them as CPAN modules today. For the few features that truly needs internals support, simply upgrade to 5.10.

When the CPAN community is reasonably happy with the tool chain, we'll see more CPAN modules written with "use v6-alpha;" as their first line, calling for more integrated internal support in Perl 5.12. When all of it works well together enough that TimToady++ is happy to declare the syntax stable, then it'd be time to drop the "-alpha" suffix. Which wouldn't be this Christmas, but the advent has started now. :-)

Replies are listed 'Best First'.
Re: Perl 6 and CPAN
by audreyt (Hermit) on Jul 23, 2006 at 05:07 UTC
    That plan, however, omits one part of CPAN: It cannot get all the Inline::* languages play well with each other. Fortunately, the Parrot project is making a director's cut of all dynamic languages, and have them play well with each other...
[reply]
      Question for you.

      You are a lot closer to Parrot development than I am. However as an outsider I've given up on Parrot achieving its original goals. Has there been any sign that what I complained about there is changing? Is there, for example, any sign that we will someday have a version of Python running on Parrot that can pass the Piethon? Like the Python and JPython do, and IronPython almost does.

      After this I've wondered from day one how incompatible behaviours between different languages will be handled. Everything from minor discrepancies (eg whether you create new copies of data upon assignment, or upon modification) to major design issues (eg how you break down your error-handling hierarchy). But over time I've become convinced that we'll never get to the point where we have to worry about that.

      I'd love to be wrong on this. I really would. But I fear I'm not.

[reply]
        Random thoughts, not necessarily answers...

        It is possible for multiple languages to agree on a shared calling convention, and hide all mismatches behind their different object types; that's what the PMC design set out to do, and it's a reasonable solution to that problem. It is also possible to implement things in the most general possible way (e.g. resumable continuations for exceptions), and all high-level languages then build their specific ways based on them.

        Based on my own experience in targeting Parrot, and also because I've seen how they are solved in CLR, I think Sam's problems have technical solutions, and the design of Parrot is sound.

        However, JVM and CLR are getting much better support for dynamic languages in their upcoming versions (especially CLR, now both VB and IronPython people are pushing it): Features such as AUTOLOAD, per-object methods, and constraints on dynamically-typed variables are finding their way into CLR. It's also possible to add runtime resolution to CLR's already Perl6-compatible static MMD (known as "method overloading" there).

        Jython and IronPython exist for a reason -- Python people want to access the existing libraries readily available in both cultures. Furthermore, I think CLR people did a pretty good job in coming up with a BCL (Base Class Libraries) that are larger than Python's core library, so it's reasonably easy to reimplement the standard Python libraries on top of them.

        Parrot doesn't yet have the equivalence of BCL, so the language implementor's job is much harder. However, the Tcl people are working on that (e.g. the OS.pmc for files and directories handling), so there is indeed progress.

[reply]
Re: Perl 6 and CPAN
by ForgotPasswordAgain (Priest) on Jul 23, 2006 at 18:13 UTC
    To me, Perl 6 is like a director's cut of CPAN.

    So, will Han shoot first? :D

[reply]

In Section Meditations