On Apr 26, 2007, at 8:28 AM, James E Keenan wrote:
Allison Randal wrote:
Nicholas Clark wrote:
I guess that the most obvious current thing that ties Parrot to the
Perl
community is that Parrot requires a copy of Perl to bootstrap, and
all the
build tools are written in Perl 5.
This is slated to change before the 1.0 release.
Since November I've been working on maintaining those of Parrot's
configuration and build tools written in Perl 5. Lately I've been
trying to recruit others to help in that process. The discussion in
this thread suggests that at some future point some or all of the Perl
scripts/modules I've been working on will be replaced with ...
something else.
This, of course, makes me wonder what I'm doing now and, more
importantly, makes me wonder what to say to other people with Perl 5
skills who want to help with the Parrot project.
This is not simply an ego thing on my part. I've written very little
of the Perl 5 tools and taken on maintenance of a bit more, but one
thing I realize is how much of Parrot's source code is written in Perl
5. How much of that must eventually be replaced?
And who is going to maintain it? In my experience Perl 5 programmers
are relatively abundant while C programmers (these days) are rarer.
How many people might actually learn the yet-to-be-designed HLL that
would presumably replace a lot of the Perl 5 we currently use?
So, can someone draw a roadmap of:
-- *which parts* of Parrot's configuration and build tools *need* to
be replaced with something else;
Everything using perl5, since parrot will ultimately help to get rid of
perl5, until a perl5 port comes along. You could theoretically use
perl6, but that would presently hurt portability(since pugs uses ghc).
-- *why* that replacement is necessary;
There won't be a perl5 to depend on. Currently, building perl5
requires perl5, which can be difficult with porting. Plus parrot's
config is greatly dependent on perl's config instead of having it's own
config.
-- *when* in the design process that replacement must take place; and
I've never heard of a timetable for this one. I know it's been a goal
for a long time now. I've often thought about the various ways to
cleanly bootstrap parrot with as few external dependencies as possible,
and to make those dependencies as generic as possible. But I have so
little time available so have never got to the point of actually coding
to see how to do a clean bootstrap, so no reliance on an installed perl
or parrot.
-- *how* that replacement will be maintained going forward from there?
With the right abstraction in the right points, a proper directory
layout, and good documentation, it'll be good. Plus, starting from
scratch is always a good thing, sometimes...
If this is already discussed in some of the design documents, I would
appreciate a link. Thank you very much.
kid51
I think the first step would be to decide how to bootstrap a miniparrot
easily, either via a generic makefile and a predefined config.h, or a c
program to probe and build whatever. Actually implementing that step
wouldn't need to be immediate. Then to figure out what the bare
minimum of parrot would be needed, most likely be writing a
Configure.pir set of code(and if we abstract enough, other programs
like perl6 and ruby would use it for whatever configuration they need,
such as for building dynoplibs and dynpmcs). Then we'd just need to
build a parrot that can support just that, which wouldn't require any
jit, or cgp cores, or have to deal with threading. Plus that so called
miniparrot could also be used some for an embedded parrot.
After knowing what's needed to configure for parrot, the next step is
probably the build tools. We know we our aim is to replace perl5 in
the long run, and that perl5 won't be available eventually(how many
systems contain perl4?).
Other than "parrot will eventually use miniparrot to configure and
built itself" I don't believe there's been a lot of discussion of just
how to go about it. All I've had time to do is ponder how to do it
cleanly.
