Will Coleda <[EMAIL PROTECTED]> wrote: > >> There is still some usage in unmaintained language implementations: > >> > >> BASIC/compiler unmaintained ? > >> BASIC/interpreter unmaintained ? > >> forth unmaintained ? > >> miniperl unmaintained ? > >> parakeet unmaintained ? > >> regex unmaintained ?
Speaking of which, some of these probably could/should be nuked. Forth hasn't worked in ages, was in need of a rewrite when it did, and depends on a lot of old behavior that makes it mostly worthless now, I think. Some of the other languages are in a similar boat. It'd be nice if there was some policy for deleting unmaintained, unworking, and unfinished languages. We're using source control -- it's trivial to get them back if we want them, but they're just taking up space now. > Given the discussion about using new PMCs for Perl6 behavior, I still > endorse making these dynamic, removing their special status. If we > can find a language to claim them, lets go one more step and move > them under languages/. Heck, we can do what was done with the python > PMCs - just move the pmcs now to languages/perl5 sans a currently > supported language with them, where someone might claim them at some > point. I'd like to make a similar argument here. The Perl PMCs don't implement all of Perl's semantics (I don't think) and aren't actually being used by a Perl implementation. Why keep them around? I'd like to see all of the dynamic pmcs moved to languages/ or compilers/ or deleted. They're designed to not be in the core, so why are they? Most of them have never been used for anything besides a proof-of-concept. The only argument I can see for keeping them there is that they're compiled by default, so the build breaks if they do. And that's *my* 2ยข. :-) -- matt diephouse http://matt.diephouse.com