Jerrad Pierce wrote:
> 
> That would be my hope too, but as I mentioned, it is seeming somewhat unlikely.

I don't think so. There's lots of proposals out there right now, but
only a very few actually break backwards compatibility. Plus, Larry's
not going to make Perl 6 look like, as Tom would say, the "Frob"
language.

I love Perl as-is. We should fix some of the major things that need
fixing (like bareword filehandles), add some more power (like embedded
objects, perhaps), and leave the rest alone. Ripping the guts out of
Perl and replacing it with something else is not a good goal.
 
> b) That is not what it is intended for. 

Oh, I know! And that's why I think it's a decent idea. It's just my
*fear* is that is becomes ubiquitous, and people start using it where
they don't need it.

> Keep in the mind that this is not INTENDED to prevent programmers from using
> new abilities, but simply to provide a high-level of compatibility for legacy
> code.

Well, we have the p52p6 translator for some of that. If it's well
written (and I intend to contribute enormously to it to make sure it
is), then I think saying:

   Problem:  Your Perl 5 script doesn't work in Perl 6
   Solution: Run p52p6 on it. The old one will be saved
             as [script].perl5
 
Is really not that bad, even with hundreds of scripts:

   $ p52p6 *
   converting myscript.pl...
       [1] saving old one as myscript.pl.perl5
       [2] parsing and upgrading code statements
       [3] testing compilation...success!
   skipping mycode.c - not a Perl script
   converting myscript2.pl...
       [1] saving old one as myscript2.pl.perl5
       [2] parsing...

-Nate

Reply via email to