"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> However, I don't think we should dismiss it out of hand because people don't
> do a lot of systems programming C. some of the things we are going to build
> for C (if that's what we pick), are already there automatically in Java,
> such as:
>
> * garbage collection for internal data structures
I'm not sure that Java's GC does what we need Perl's GC to do.
Particularly the timely calling of DESTROY and friends.
> And, it will make the barrier for entry for new internals hacker
> lower.
Err. How do you get to that conclusion? The thing that really stops me
mucking about with perl's internals is the fiendish complexity of said
internals. Changing the programming language will not, of itself,
reduce that complexity.
> > 1) Targeting a single compiler, no matter whose it is, is a bad
> > idea. We're writing in a *language*, not for a compiler. Targeting a
> > specific compiler restricts us even more than choosing a language.
>
> I would note that if we write in Java, we aren't targeting a single
> compiler, although at the moment, the only efficient compiler for
> Java might be GCJ.
Hmm... Up to a point, Lord Copper.
> > 2) GCC produces slow code on all platforms where there's an
> > alternative.
>
> This is likely going to change with the release of GCC 3.0, based on
> current benchmarks of test releases of GCC 3.0.
Err, are you seriously suggesting that we implement Perl 6 using a
language which currently only has one 'efficient compiler' (to native
code), when said compiler isn't actually there yet?
I think that that would be a 'courageous' decision.
--
Piers
