Simon Cozens <[EMAIL PROTECTED]> wrote:
> It seems like everyone has their axes to grind on this one: Bradley thinks
> the world must be built in Java,
I don't believe that. There has been a misunderstanding, and I apologize if
I didn't communicate that effectively.
I don't really care *that* much if we implement the canonical version of
perl6 in C, Java, or the Foobar language. I made a case doing the canonical
implementation of perl6 in Java, which was shot down with valid and good
technical arguments. I won't make the case for it again.
However, I will continue to make the case that we not ghettoize systems that
don't have a native C compiler. I ask that the PDD's not be language
specific (except those that specifically deal with implementation details in
C, of course).
What I seek is perl design documentation that allows someone to take the set
of PDD's and reimplement perl in another language. I don't expect to be
handed an implementation of Perl in Java (although I tried, and failed, to
make this happen because it would be nice ;), but I would like to have it be
possible, without having to spend weeks reading the source code for the C
implementation of perl. (As is required if you want to even make use of the
B:: backend of perl5 to do useful work.)
The current perl5 implementation does not easily facilitate growth for the
internals of perl into new directions. People who want to reimplement Perl
in interesting ways can't do it right now, without having guru-level
knowledge of the current perl6 implementation.
Perhaps people want to experiment with new ideas of language integration.
Perhaps they want to run Perl natively on the JVM, or in C#. Or, perhaps
they just to reimplementation some part of Perl to learn more about Perl and
compiler technology in general. (Indeed, imagine if college compiler
courses used perl6 to teach students compiler design!). And, there are
probably more ideas that no one has thought of yet.
Since we are starting from scratch, why not make these things possible if it
isn't too hard? And, I don't think it is, if we are simply mindful to "not
be C specific" as we design.
> > My concern is *can* we support it on architectures that don't have a native
> > C compiler (i.e., the JVM).
> So port GCC to the JVM, solving all your problems and a lot more besides.
There are folks working on this, and it's a good idea. However, it is a
very difficult problem to have a C port to the JVM that is as good as native
ports, because the JVM is more than just a bytecode architecture.
A C port the JVM has little choice other than to treat the JVM like "just
another processor". But the JVM isn't just a processor, it's also an object
model. If a port isn't aware of that object model, then the usefulness of
the JVM port is greatly reduced. I'd be happy to talk more about this with
you off-list if you are interested.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
