in reply to Perl 5 <-> Perl 6 compatibility: a benefit or a mess?

Does this mean that all the modules available from CPAN for Perl 5 will be available for Perl 6 too without modification?

All the modules? "All" may be unrealistic, but a percentage in the high 90's is what I am expecting. The most valuable thing about Perl is all the code already written on CPAN; it will *not* be abandoned. Perl 5 may not be able to use Perl 6 CPAN modules as of 5.8, (the current use v6-alpha is deep non-generalizable black magic, I think), but I *hope* 5.12 (the version with Parrot underpinnings) will run Perl 6 modules, and I *expect* and *depend* on Perl 6 to run Perl 5 modules on day one of its release.

...will have to learn 2 different languages instead of only 1 (Perl 5 + Perl 6), or they won't be able to understand all the Perl 5 stuff that is already done (and still in use in Perl 6 scripts).

Just because you *can* include inline Perl 5 code, does not automatically mean you *must*, or even that you *should*. A new Perl programmer, trained only in Perl 6, tasked to write only new code, should not need to know or use anything of Perl 5 syntax, except perhaps to understand example code embedded in the POD of Perl 5 modules on CPAN. Likewise, some people programming Perl 5 today will have the option of doing maintenance of just Perl 5 code for the rest of their careers; businesses hate re-writing bread-and-butter code.

I expect that the mix-and-match coding of Perl 5 and 6 in a single program will mainly be used by programmers who *already* *know* both 5 and 6, and will only stay mixed during a transition of the program to 100% Perl 6. The inline mix-and-match ability, if actually delivered in Perl 6 1.0, will be invaluable when converting a program of any significant size; piecemeal refactoring with incremental automated testing will go so much smoother than all-in-one-shot rewrites.

Also, I encourage you to study the final section of the first Exegesis. It focuses on how much of Perl 6 is *unchanged* from Perl 5, if you do not use the new optional features.

Am I completely wrong?

Not *completely*; there will be time lags in training, mis-matches in skill sets, bad decisions on partial re-writes in some IT departments, and many other 5=>6 issues. Those are all worth giving thought, so that guidelines can be written for those who will be converting their code over time. None of that is reason to remove the capability to do inline mix-and-match coding. The Perl TIMTOWTDI philosophy guides us; better to provide too much function than too little.

Replies are listed 'Best First'.
Re^2: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by moritz (Cardinal) on Jun 18, 2007 at 17:35 UTC
    Just a random moose...

    Why should a perl 6 implementation not be able to run all perl 5 modules?

    After all it will have to have a perl 5 interpreter linked to the core (because an eval($perl_5_code, :lang<perl5>); could always occure somewhere), so if the bridge between 5<->6 is good, there shouldn't be a problem.

    Or is it that hard to build the 5<->6 bridge?

    Perl 6 in German

[reply]
[d/l]

      For the same reason Perl-5-on-Parrot has (or will have) problems running some Perl 5 modules: XS.

      Some modules are partially implemented in C, and are hooked into Perl code via a combination of C macros and Perl pre-processors collectively called XS. This process relies on particulars of perl internals that pure Perl code (and pure Perl programmers) never need be aware of. Those particulars are monumentally different in Parrot.

      Since the macros define a sort of API to the perl internals, replacement macros should be able to be written to create a work-alike interface into Parrot. Last time I checked, this was expected to be the major sticking point for the someday-release of 5.12, the first official Perl 5 to run on Parrot, with the old virtual machine internals ripped out and left on the trash heap. This re-macroed API is a tough job, but looks definitely do-able.

      Unfortunately, some of the C code in some of those modules does *not* use the API macros; the programmer instead wrote the C code to *directly* communicate with the perl internals. This may have been for performance, ignorance, or the absence of an API macro at the time of the writing. It is these modules that are the true thorns that keep anyone from promising 100% compatibility with Perl 5 modules. Such code will require changes that only the original author might be qualified to make. Such code will also be very difficult to identify by inspection; after the replacement API macros are written, you will only know you found a XS thorn when it fails to pass its tests. Those lacking tests will only be spotted when they fail to *run* correctly.

      Caveat: I've not been deep in the Parrot guts for over a year; any of this could be *completely* wrong.

[reply]

In Section Seekers of Perl Wisdom