David L. Nicol writes:
> RFC: Perl6 is Final. There will Be No Perl7
>
> We declare that our framework willbe so flexiblke
> that anything can be done with it and there will be no penalty
> for something being in-core opposed to out-of-core and so on.
Bad idea. You can't make anything infinitely customizable without
making it an infinitely slow bitch. Genericity costs. I say we make
the best perl6 we can, and let the inevitable perl7 take care of
itself.
Of course we don't want to be too locked in, but neither do we want to
be too flexible (IMHO). This is, of course, inherent in the word
"too".
> RFC: The perl6 reference implementation, no matter how slow it is,
> will be written in perl5, in some kind of well defined virtual machine.
> It should be possible do Data::Dumper out a emulated perl6 instance
> and load it into another and there you are, except the file handles
> are all confused (unless you've got a way-fancy OS that can cope with
> such things)
Aye aye aye. I'd like to see proposed language features prototyped or
emulated in perl5. But I'm unconvinced that implementing perl6 first
in perl5 is going to win us much more than a big delay. You're going
to find correct threading and signals hard to emulate on a system with
broken threading and signals, though.
> RFC: It's all exception handling. I imagine the core syntax description
> as a set of catch clauses. Every token generates a "TOKEN-$whatever"
> exception, which is caught according to the current situation. How's
> that for a general paradigm? These things can be overloaded as needed to
> implement Macros, variant syntaces, variant semantics, and so on.
My first reaction is "wouldn't that be slow?"
Nat
