however my question is why an interpretor...
Historically that is, are there strong advantages to
creating an interpretted language over a compiled one. I am still not really sure I understand why a
compiler for perl would be such a bad idea. What aspects of the language could not be supported by a
in reply to Why has perl never been a compiled language...
A compiled Perl script needs
to have the whole Perl compiler/interpreter (it can be called
either or both, depending on your point of view) bundled with it
mostly because of `eval STRING'. For `eval STRING' to work,
you have to be able to do everything you can do in the compile
phase at runtime.
This topic just yesterday came up on the perl6-internals list.
As it hasn't yet been captured by mail-archive, here's a message
The problem isn't the speed of `eval STRING' or the compilation system,
it's how to make it exist and work. To make `eval STRING' work, the
whole of the compiler has to be there, waiting, whenever a program is
run. That means a theoretical binary compile of `print "Hello world\n"'
has to come packaged with howevermany megs the Perl executable takes up.
And that all ports, for example JVM and Palm, have to implement the
compiler natively, rather than just having code compiled elsewhere and
sync-ed to the Palm or run from the JVM.
Simply deciding that `eval STRING' is "unimplemented" on these
theoretical ports and binary compiles is the best idea I've heard yet,
but we should remember that `require' is built on `eval STRING'.
There are a lot of issues involved here, but that's basically
the executive summary of why all of Perl can't be supported
by a "reasonable" compiler.