Where's the application-level sweet spot most likely to be in designing and implementing for Parrot? Language specifics or internals aren't really on my mind in this question.

Although this may fall under the internals category, I think it'll be in embedding and extending. Their interfaces will be far more well-defined than in Perl 5, which will be a big win. If these interfaces are only as clean as the rest of Parrot (and they're expected to be cleaner), C-level work will be much more accessible to J. Random Hacker.

And philosophically (and possibly rhetorically): Since Parrot will be extensible to allow runtime use by many languages, is this the logical extension of "glue language" philosophy applied to the now separate VM? Is Parrot the result of many Secret Meetings in order to conquer the world with a Unified Language Theory in practice? :) If Parrot succeeds on a grand scale, will it take on a life of its own and no longer be necessarily associated with Perl itself?

It is my hope that Parrot's association with Perl eventually becomes irrelevant to anybody but computer historians. Not only does this mean that Parrot can survive even if Perl doesn't (which I don't expect to happen, but who knows?), but it'll help users of other languages (*cough*Python*cough*) to see Parrot for its own benefits and not just as part of The Enemy's language. And that, I believe, will benefit everybody.

=cut
--Brent Dax
There is no sig.