|
zigster has asked for the wisdom of the Perl Monks concerning the following question:
I have been a little bored recently so I have been looking around the monastery and came across the node Compile Perl??? it talks about the fact that to compile perl you would need to embed a perl interpreter into the final binary (sounds v nasty ;-) I read On Parsing Perl where merlyn explains how damn hard it is to parse perl, so I can see that creating compiled that could parse perl would be very very hard, 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 compiler?
--
Zigster |
Re: Why has perl never been a compiled language...
by AgentM (Curate) on Dec 06, 2000 at 21:47 UTC
|
Actually, a while back (1996?), there was a guy working a Perl compiler which was specifically optimized for use with gcc (yacc). This compiler parsed to generate C code or optionally assembly (via gcc). I even believe that it did not embed a parser in the final product though, except for evals (that was the last time I checked, so I may be wrong now). Supposedly, the guy was working on some heavy optimizations which would make Perl code much more comparable to C code (concerning speed) and it even supports making .so of .pms which is just plain cool. I don't know if there's progress on it, though. Malcolm Beattie, the author has also created B::C and B::CC specifically for the purposes of optimizing his compiler. All in all, it's pretty cool, since it results in what I like to call "assembler obfuscation" which would prevent those pesky clients from screwing with a chmod they imagine is unsafe which damages a whole bunch of directories (personal experience) or Ovid's boss from writing File::Find which erases the entire development environment. Of course, I expect many arguments as to why perlcc may be useful or not, but the way I see it is that this guy has put lots of effort into a cool program, so its at least worth a try. In at least one distro (the one I have <5.6), perlcc is included by default (or was it thrown in by someone else on my linux cds?) I dunno, but it's not something to overlook and I hope Mr. Beattie is continuing his work on it- I can't be sure since the docs are somewhat outdated.
If you're wondering about possible advantages of an interpreter over compiled code...then the basic arguments are these-
- interpreter is slower than a compiler- while this is generally true, the advantage of using a friendly language like perl outways this argument. Also, using mechanisms like FastCGI or mod_perl can easily cut down on time- alot (for CGIs that is).
- compiled code is not hhuman-readble- again, depending on the situation, this may or may not be useful.
Back in the stone age, most code HAD to be compiled simply because computters (sic) were so damn slow. Ridiculous assembler optimizations and SISC tricks were employed to cut code size and increase speed. BASIC only became popular since it was so damn easy- though insanely slow to parse and run. Nowadays, code size doesn't really matter and speed, while still a concern, is not such a GREAT concern since it doesn't matter anymore if the user waits an extra tenth of a second long for the same operation that took an annoying 20 seconds ten years ago. So, I see that the farther we go along, the more and more compiled code will be used as a code-hiding mechanism rather than simpy a speed improvement. For example, the fact that M$ wrote Windows in Visual Basic (a historically interpreted language) shows that they showed very little concern for speed or any other type of optimization.
More info (docs) here.
Embedding Perl in C is insanely simple- look at perlembed- the result is a compiled program with an embedded perl parser which will happily run any text that you pass to it.
NOTE: Since it is outdated, this information may not be relevant or even correct. Parental discretion is advised. Please correct me if I'm wrong and reply with any new information since it would certainly interest me, too. Thanx.
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
Re: Why has perl never been a compiled language...
by dchetlin (Friar) on Dec 06, 2000 at 22:04 UTC
|
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
compiler?
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
I sent:
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.
-dlc | [reply] |
(Ovid) Re: Why has perl never been a compiled language...
by Ovid (Cardinal) on Dec 06, 2000 at 22:00 UTC
|
eval is the problem that comes to my mind. Because you can build and execute arbitrary bits of code, you need something that can parse perl. I imagine that s///e would also be a problem. If the code that's generated is moderately complex, you would likely have bugs.
Here's an interesting bit of explanation of the current compiler status.
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats. | [reply] |
|
|
| [reply] |
Re: Why has perl never been a compiled language...
by BatGnat (Scribe) on Dec 07, 2000 at 02:02 UTC
|
Actually, I compile PERL all the time, using p2exe. Yes, it is for NT. The compiled file even if print "hello world\n"; is all it does, is 650k. You can compile it with a -small which compiles it with a seperate dll, making the actual exe smaller.
BatGnat | [reply]
[d/l] |
|
|
Where can I get p2exe? Can I get it for free? I know that is how everyone wants it!!!! :0)
| [reply] |
|
|
Is it free? Where can I get a copy if it is? Thank you....
| [reply] |
Re: Why has perl never been a compiled language...
by Cybercosis (Monk) on Dec 07, 2000 at 06:44 UTC
|
Actually, to solve the eval problem, perhaps the perl compiler could be redone to accomodate C`, the dynamic-code generation version of C, available over at MIT. Incidentally, this isn't just some random suggestion, I'm seriously starting to consider doing it (don't nobody ever say that I'm not insane ;-))
~Cybercosis | [reply] |
Re: Why has perl never been a compiled language...
by zigster (Hermit) on Dec 07, 2000 at 13:53 UTC
|
| [reply] |
|
|
