John Tobey <[EMAIL PROTECTED]> writes:
>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.
By all means have a go at Topaz-II
But it won't be 'Perl 6' unless it implements what perl-language
decides that _is_.
>
>What drives this vision, you might ask? Compatibility. XS and API
>source compatibility with Perl 5 will be much stronger this way
Hmm - personally I cannot imagine how you can maintain XS / API compatibility
and improve things ...
Nor am I sure that the XS API is not one of the things I would not
have near top of the list for "internals cleanup":
PUSHMARK;
XPUSHs(sv_2mortal(newSVpv('DeepThought'));
XPUSHs(sv_2mortal(newSViv(42));
PUTBACK;
count = perl_call_method("Consider",G_EVAL);
SPAGAIN;
if (count >= 1) {
answer = SvIV(POPs));
}
You _want_ to keep that???
And you will have to - as any non-trival XS module has that kind
of mess in it (if only in its typemaps).
>than
>with Scratch 6.0. Binary compatibility layers such as Pickle will be
>more practical, and unexpected quirky differences will be minimal.
--
Nick Ing-Simmons
