Bryan C. Warnock writes:
> Like I said, just things to keep in mind. There's a slight difference
> between designing and coding Parrot as an interpreter backend, and coding it
> as a backend to Perl that other languages can use. (I'm in favor of the
> latter, though public opinion seems to favor the former.)
Here's my Official Word. Right now it's too early to know whether
building perl6's runtime to also support other languages will impact
perl6's speed or size. We also have faced skepticism about the whole
effort from other languages.
So we're proceeding with designing perl6. We're leaving the door open
for other languages, but we're not going to significantly delay or
impede perl6 to support them. Dan and Simon have both been talking
with Python folks about their language, and I'm sure there'll be demos
to the Python crowd soon to show them that it's feasible and attempt
to get their buy-in.
If we get other languages interested to the point where we share our
internals with them, then we'll go through the painful divorce process
of dividing assets between Perl and Parrot. But until then, let's
assume that Parrot will only officially be part of the Perl project,
and focus on writing more Parrot code instead of arguing about
namespaces.
That may mean we may face a little pain down the road, but at the
moment I'm much more interested in getting something to have pain
about than I am about planning for a future that *might* come about.
If we get the other languages interested, it'd be such a big win (in
terms of development resources) that we'd be *happy* to do the work of
separating parrot from perl.
Make sense?
Nat
