Okay, we've now got minimal:
*) Parrot assembly
*) Perl
*) Python
*) JVM
*) Scheme
*) Jako
*) Ruby? (Do we? I can't remember for sure)
support for Parrot. This is a cool thing, but it brings up the questions:
1) Do we put them all in the parrot CVS tree
2) Do we require them to meet the same levels of quality as the core
interpreter?
For the first, I don't mind (I think it's kinda cool, actually) but I worry
about the possibility that things will get out of sync or fall unsupported.
I do *not* want us to feel that we can't ship, say, Parrot 0.09 because it
the Scheme compiler's not working. (For reasons unrelated to parrot, at
least... :)
For the second, I really do feel that if it's in the source tree it should
be subject to the same requirements on patches and submissions that the
rest of Parrot is. (And we're working on getting that together a set of
guidelines) That means no non-working code, good tests, and sufficient
documentation on things.
I'd be happy if the parrot kit could either ship with compiler modules &
runtime support for lots of non-perl languages or, at the very least, the
non-perl languages could each have a single install kit that could be
layered on top of parrot. (Of course, the potential for "Well, to install
that module requires installing the Ruby, Scheme, and INTERCAL runtimes"
coming up, but I'm OK with that...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
