[perl #32642] [TODO] Remove Perl* PMCs from parrot's basic PMCs
Will Coleda
# Please include the string: [perl #32642]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32642 >
Many pmcs (in classes/) are currently using Perl PMCs either as base classes or as types for contained/undef values instead of other basic parrot PMCs...
A first pass at offenders is available via:
oolong:~/research/parrot/classes coke$ grep Perl *.pmc| grep -v Foundation | grep -v '^perl'|awk -F: '{print $1}'|sort -u
array.pmc
bigint.pmc
boolean.pmc
complex.pmc
default.pmc
exception.pmc
fixedpmcarray.pmc
fixedstringarray.pmc
integer.pmc
iterator.pmc
key.pmc
orderedhash.pmc
pmcarray.pmc
resizablepmcarray.pmc
resizablestringarray.pmc
sarray.pmc
slice.pmc
stringarray.pmc
tqueue.pmc
Bernhard Schmalhofer via RT
as far as I see, the Perl* PMCs are no longer used in the Parrot core.
There is still some usage in unmaintained language implementations:
BASIC/compiler unmaintained ?
BASIC/interpreter unmaintained ?
forth unmaintained ?
miniperl unmaintained ?
parakeet unmaintained ?
regex unmaintained ?
'punie' seems to be the only maintained language implementation using
Perl* PMCs. Also some tests and examples are using the Perl* PMCs.
The next step is to make the Perl* PMCs dynamic.
What are the opinions, WRT moving the Perl* PMCs to src/dynpmc or
languages/punie/pmc ? In the latter case they could be renamed to Perl1*.
Regards, Bernhard
--
/* Bernhard.S...@gmx.de */
Patrick R. Michaud
> Hi,
>
> as far as I see, the Perl* PMCs are no longer used in the Parrot core.
>
> There is still some usage in unmaintained language implementations:
>
> BASIC/compiler unmaintained ?
> BASIC/interpreter unmaintained ?
> forth unmaintained ?
> miniperl unmaintained ?
> parakeet unmaintained ?
> regex unmaintained ?
>
> 'punie' seems to be the only maintained language implementation using
> Perl* PMCs. Also some tests and examples are using the Perl* PMCs.
There has been some discussion of this. First, Chip has declared
that Parrot won't change significantly until 1.0, and in some
respects I think this may include the Perl* PMCs.
For the Perl 6 compiler, we will likely create a separate set
of "Perl6*" PMCs. I'm hoping that we can build a common set of
Perl6* PMCs that would meet the needs of the p6 compiler, Pugs,
and whoever else may need PMC objects with Perl 6 semantics.
Pm
Chromatic
> 'punie' seems to be the only maintained language implementation using
> Perl* PMCs.
What about Ponie?
> Also some tests and examples are using the Perl* PMCs.
I agree that they probably shouldn't, except for the tests for those PMCs
themselves.
-- c
Will Coleda
On Apr 6, 2006, at 5:08 PM, Patrick R. Michaud wrote:
> On Thu, Apr 06, 2006 at 02:04:06PM -0700, Bernhard Schmalhofer via
> RT wrote:
>> Hi,
>>
>> as far as I see, the Perl* PMCs are no longer used in the Parrot
>> core.
>>
Thanks, Bernhard.
>> There is still some usage in unmaintained language implementations:
>>
>> BASIC/compiler unmaintained ?
>> BASIC/interpreter unmaintained ?
>> forth unmaintained ?
>> miniperl unmaintained ?
>> parakeet unmaintained ?
>> regex unmaintained ?
>>
>> 'punie' seems to be the only maintained language implementation using
>> Perl* PMCs. Also some tests and examples are using the Perl* PMCs.
>
> There has been some discussion of this. First, Chip has declared
> that Parrot won't change significantly until 1.0, and in some
> respects I think this may include the Perl* PMCs.
>
> For the Perl 6 compiler, we will likely create a separate set
> of "Perl6*" PMCs. I'm hoping that we can build a common set of
> Perl6* PMCs that would meet the needs of the p6 compiler, Pugs,
> and whoever else may need PMC objects with Perl 6 semantics.
>
> Pm
>
The existing Perl PMCs are not part of parrot's design at the moment,
SFAIK. Changing them to dynops is, in my opinion just an
implementation detail. The only reason they are used at all in the
languages listed above (aside, perhaps, from punie) is that parrot's
core PMCs came later - they used the most functional PMCs that
existed at the time. If there's no compelling reason to keep punie
using the Perl5 pmcs, I'll happily patch it to use core PMCs instead.
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.
My 2₫.
Nicholas Clark
> On Thursday 06 April 2006 14:04, Bernhard Schmalhofer via RT wrote:
>
> > 'punie' seems to be the only maintained language implementation using
> > Perl* PMCs.
>
> What about Ponie?
Ponie isn't using them.
Nicholas Clark
Matt Diephouse
> >> 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