At 11:12 PM 12/5/00 -0500, Bradley M. Kuhn wrote:
>Simon Cozens <[EMAIL PROTECTED]> wrote:
> > Of the suggestions that have been advanced so far, four are worthy of
> > more consideration: C, C++, Java and a specially-designed Perl
> > Implementation Language. (PIL)
>
> > Java is portable and gives us OO, but it's slow and ugly.
>
>I am probably the biggest proponent of the "use Java to implement Perl"
>camp.
>
>And, on this front, I would like to comment. First, "ugly" is a matter of
>taste, and I don't think we should let that be a deciding factor. Every
>programming language is ugly in one way or another.
More importantly, what we're doing is outside Java's area of competence.
We're writing system-level code here. Java isn't a system-level programming
language. This isn't a bad thing, but it means it's an inappropriate
solution to the problem. We might as well write perl 6 in perl.
>As for "slow", this will be helped by GCJ, the new GCC 3.0 front-end for
>Java. Java will compile to native code, via GCC.
>
>GCJ is not yet ready for prime time, so I certainly understand reluctance on
>building on infrastructure that isn't done yet. However, if we, as a team,
>decide that Java is a real contender, I will volunteer to start monitoring
>GCJ's progress. It might turn out that GCJ will be ready "just-in-time" for
>us to use it to implement Perl. ;)
>
>I know there is great resistance to requiring GCC, and I remember those
>threads. I believe this was mostly from the VMS camp. So, is there a
>native-code Java compiler for VMS?
No, there isn't. I object to targetting GCC specifically for two reasons,
though, neither of them VMS related:
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.
2) GCC produces slow code on all platforms where there's an alternative.
Compaq C beats it on Alphas and VAXen, Sun's compiler beats it on SPARC
machines, and HP's beats it on PA-RISC machines. Heck, Microsoft's compiler
beats it on x86 chips. (As does Intel's compiler) We want perl fast, and
crippling it by requiring a particular compiler's a foolish thing.
There's no reason I can see, outside of ideological ones, to require gcc.
[vtable stuff snipped]
I don't think it's too early to be dealing with the way variables are
implemented, at least at some level. Also, just because we do vtables under
the hood doesn't mean that any port of perl needs to do it that way--all
that's required is to support the exposed interface, and the vtable stuff
is definitely in the "hidden guts" realm.
> > =head2 Memory Allocation
>
> > Memory allocation's pretty much a solved problem, so this shouldn't need
> > to require much thought.
>[...]
> > =head2 Garbage Collection
>
>I would like to note that GCC has actually switched to using garbage
>collection to manage its *internal* data structures rather than a
>traditional C memory management system. The GCC team has been pleased with
>both the performance and ease of use.
>
>The argument is: "Computers do a better job at memory allocation than humans
>do by hand, so let the computer do it!"
>
>I think we should give this idea some serious consideration.
That works, though we have issues the gcc folks don't have, seeing as we
have to manage memory allocated by the compiler piece as well as by the
interpreter piece. Whether a full garbage collection system for the
compiler's a win is up in the air (automatic GC for C code's a pain, and
all the ones I've seen are ugly), but if we can pull it off that's fine.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
