Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I'm thinking of a rewrite in the sense that (by my impression) BSD was
> > a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> > to get a handle on things, and replace it all a little at a time. So,
> > yes, these problems can be solved IMHO, after "enough" of Perl 5 has
> > been rewritten.
>
> Is that Perl 6 you're talking about or Perl 5.8? I mean that. Perl 5
> will continue its development while we're doing the rewrite. Incremental
> changes would be best done in the 5.7 series, no?
Perl 6. 5.8 will contain incremental improvements and added features,
but 6.0 (what I'll call "Morph 6.0" as opposed to "Scratch 6.0") would
be much more aggressively changed. Backwards compatibility would be
salable, source files rearranged, and the guts scarcely recognizable
in the end, but as a result of evolution, not revolution.
The people here are rightly skeptical about the effectiveness of using
the 5.6 code base as a starting point for v6, but I have a pretty
clear vision of how to do it, and I am committed to giving it a try,
even if no one else will. In fact, I'll give you all a tentative
schedule:
15 August 2000 - detailed draft spec to perl6-internals.
31 August 2000 - revised spec after discussion.
1 November 2000 - Perl6 alpha in C++ that uses classes derived
from PerlInterpreter and SV everywhere in place
of these types, a la Pickle, but with inline
methods that use Perl 5's internal API.
1 June 2001 - Perl v6.-1.0 (eek!) that passes all tests
(troublesome tests will have been removed or
changed) and has in place the necessary
abstractions for unplugging and plugging core
component implementations. Probably a GLib
plugin proof-of-concept.
At least once a month, though not at regular intervals, a report of
the test suite status will be posted on the Web, including tests
failed and some discussion of why and what is to be done. A lengthy
discussion will be required if more than 20% of test scripts are
removed or fail for any given month.
This schedule will be accelerated about 2x if somebody hires me to
work full time on it. (AS: My requirements are modest! :-)
I will start by using C++ where applicable for ease of development,
but I will try to keep open the possibility of switching the core
implementation back to C once it's past alpha.
Unicode and threading would become integrable only after a lot of
morphing (refactoring). The morphing would probably destroy any
traces of v5 unicode support (since well under 20% of test scripts
will notice), and of course 5005threads will be the first to go. With
any luck, a compatible, well-integrated replacement will eventually
take its place.
What drives this vision, you might ask? Compatibility. XS and API
source compatibility with Perl 5 will be much stronger this way than
with Scratch 6.0. Binary compatibility layers such as Pickle will be
more practical, and unexpected quirky differences will be minimal.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
