Front page | perl.perl6.internals |
Postings from September 2002
Parrot long-term goals/prospects
Thread Next
From:
Dan Sugalski
Date:
September 5, 2002 04:03
Subject:
Parrot long-term goals/prospects
Message ID:
a05111b19b99ce25b9a81@[63.120.19.221]
I really hadn't planned on going into this now, but the issue's been
raised enough that it can't be left to later. Here's the current set
of long-term goals for Parrot:
1) We *will* run Perl 6, Perl 5, Ruby, Python, JVM bytecode, and .NET
bytecode. Not necessarily in that order
2) perl6-internals@perl.org list at some point transitions to being
for perl 6 development
3) Parrot development moves to parrot-dev@parrotcode.org
4) The *only* tools you will need to build parrot are a C compiler
environment and either a make tool or a shell
5) Build environment bits may be in any language that the current
maintainer is comfortable with as long as the language they're
written in is available at the point in the build they are needed
6) Perl 6 is hosted on Parrot, and Larry gets no more special
treatment than any other language designer of a language hosted on
parrot does.
7) POD will remain our documentation format, unless/until someone
comes up with something equally easy to read and write without any
tools. We can mutate it to our needs, and if so we'll give it a new
name.
8) Forth and Scheme may well be maintained specifically for whiny
language bigots
9) The perl-specific bits of Parrot will get isolated into a perl
directory and treated as add-ons
What does this mean? Well, here are the footnotes.
#1: means that we're looking to be multi-language. Really.
#2 & #3 will make things tricky for google, history, and whatnot. We can deal.
#4: The current reliance on Perl will remain until parrot's
sufficiently self-hosted that we don't need an external perl
environment. We will *not* add any other add-ons, though we may be
forced by ICU to add C++ to the list.
#5: It's perfectly acceptable to ship bytecode-compiled programs the
build uses that are generated from languages that aren't yet built.
(So part of the build could be done with bytecode programs generated
from, say, Ruby or Python, that Parrot executes even if Ruby or
Python hasn't been built yet. Or at all, if it's a minimal Parrot
build)
#6: This doesn't mean Larry's privs are restricted. Far from it. It
means that other people can ask for the same sort of stuff, assuming
Parrot is well and truly a primary target. This includes Guido, Matz,
or anyone with their own custom language. (We reserve the right to
tell everyone "no" on core engine changes however)
#7: There's nothing fundamentally wrong with POD. It's simple and
easy and, while limited, requires little effort to write. (The first
person
#8: No, not for whiny Forth and Scheme bigots. For whiny language
bigots of other languages. Start spouting off about how X is clearly
the superior language and we'll only accept patches from you in
Forth. Unless X is Forth for you, in which case we'll only take
Scheme patches.
#9: It's likely that miniperl will be a required build component for
quite a while, though I'd prefer to not have it so. The core parrot
engine will *not* require perl being built, though some of the
default behaviour may be perlish for quite a while. No other language
is required to accept the core behavior, though.
The time to implement these, however, is *NOT* *NOW*. The benefit for
tossing over perl for something else (or nothing else, and maintain
some sort of aloof independence) is non-existant. When the engine is
fully specified and built then things may (almost undoubtedly will)
change. Talk of, or actions towards, independence when we don't even
have objects spec'd out is pretty stupid, though.
So, there you have it. The plans for World Domination.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Next
-
Parrot long-term goals/prospects
by Dan Sugalski