> Still, I'll be really, *really* surprised if most perl code require any
> rewriting to run under perl 6. TomC's got quite a cache of old perl code,
> and I've got some mildly hairy perl 5 code that I want perl 6 to eat
> without complaint.
OK. But by the current thread, this ability of perl6 to interpret perl5
needs a toggle, be it a package/module declaration, a #! switch, whatever.
That is, the syntax will not be compatible. Whether the perl6 interpreter
is *able* to 'do' perl5 is not so much the issue as how it will do it. So
already you have broken perl5 insomuch as it has to be interpreted *as*
perl5. From here on out, it's just a matter of implementation. Do you use
a switch, do you use a different interpreter. Does the switch actually
just fork another interpreter?
I suppose the talk of a ubiquitous "meta-language" which allows you to
write perl with whatever syntax you choose would solve this, but I am
highly skeptical of anybody's ability to define such a language that would
accomodate obfuscated perl5. Imagine how that would look.
> Yeah, but innovation at the cost of legacy's not a great idea either. Don't
> forget we have an enourmous legacy base--every single person who programs
> in perl now. This is probably our last chance for a big language upheaval
> for quite a while, but that doesn't mean that we're actually going to have
> that much of one.
Well, it is going to be substantial. Again, if we need to differentiate at
interpreter startup, regardless of the implementation, it is going to be
substantial. Otherwise, perl6 should just be able to know the difference
when it encounters small syntactical differences, and we wouldn't be
having the conversation.
