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

Reply via email to