Johan Vromans writes:
: Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
:
: > perl.exe + perl.dll or .../bin/perl + libperl.so
:
: RFC: Should the perl program be called differently (e.g., perl6) to
: allow sites to run 5 and 6 in parallel until their migration is
: completed (if ever)?
We will certainly have to distinguish the executables.
I will go farther than that, and say that we will fail if we do not
build Perl 6 in the same distribution tree as Perl 5. Yes, we're
redesigning Perl 6 from scratch, but I think that for a long time yet,
we will need to keep the scaffolding of Perl 5 around Perl 6. Keeping
them co-located has a number of advantages:
* We know which version of Perl 5 we're using to build Perl 6.
* We can make calls back into Perl 5 to emulate things not yet
implemented in Perl 6.
* We make it obvious that Perl 5 is still very important to us.
* We keep Perl 6 in front of everyone's nose even if they aren't
interested in using it yet.
* We can evolve the Perl-5-to-Perl-6 translator as we go.
I basically used the emulation approach to write Perl 5, so I know it
works. There were some intermediate forms of Perl where some of the
opcodes ran Perl 5 C code, and some of them ran Perl 4 C code.
My basic underlying point is that you can be revolutionary in design,
yet evolutionary in implementation of that design. And that taking
such an evolutionary approach has the advantage of not letting the old
guard think they've been totally abandoned. (Witness the problems of
perceived abandonment with the Mozilla rewrite.)
We may, of course, decide to do something so different that there's
no way to write the glue to call back into Perl 5 for unimplemented
opcodes. If that's the case, it might be a danger signal that we're
overreaching, and we'll have difficulty dragging Perl 5 code into the
Perl 6 world.
I could be wrong about that. Whether or not we use Perl 5 to emulate
unimplemented opcodes, we still to keep Perl 6 near Perl 5 for all the
other reasons.
Larry
