On Mar 20, 2004, at 20:35, Andrew M. Langmead wrote:[stuff deleted]Perl 5.005 and later ship with a perlcc script and the supporting infrastructure to make binary executable files out of perl scripts.
Wow - what a bummer. Time for me to find my ancient "compiler" textbook, mayhap, and write one?
Chuckle!
Its not the funniest of ideas. Some people say that free and open source software gets made when someone has an itch to scratch. If a compiler is important enough for you to want it done, it can be done.
Sometimes even if you don't meet the goal, the end result isn't a disaster. I never use the
perl compiler, but I do use "-MO::Deparse", which uses much of the same compiler infrastructure.
be surprising. (I guess "never compiles" is a subset of "runs slower", and that is a very common situation when dealing with perlcc)Drat. I wonder why!
(I'm not sure you are wondering about the "runs slower" or "never compiles" part, but that is my fault for mixing up the two issues. I think I'll further the problem by conflating both answers.)
What the perl compiler subsystem does is take the parse tree created by the parser, and pass it to some modules to poke around in it in odd ways. The "O::CC" and "O::Bytecode" modules try to emit a C datastructure or a bytecode representation of the syntax try. (the Deparse module mentioned above writes it back out as perl code. It may not sound useful, but the Deparse module isn't nearly as clever as the programmers whose code I occasionally have to maintain, and sometimes that is a feature.) Once source code modules written out by the "CC" module contain the data structure, along with some code to connect pointers to the pieces of the datastructure together boilerplate the code to load up an interpreter and hand it the syntax tree back.
An executable from the perlcc program, if it hits nearly all the advantages and misses nearly all the failings of the "CC" module will nearly only save start up parsing time. At worst, the startup overhead of the fixups and boilerplate code is longer than the original parse used to be. Retrofitting a system like this onto the language ten years after the fact made it difficult to play nicely with other pieces. (For example, BEGIN blocks, including the implicit BEGIN blocks of "use" can have some surprising effects when you consider the fact that they are run at "compile time" and under perlcc that "compile time" is an entirely separate process, at a separate time, and possibly on a an entirely different machine than when the program runs.) Having a perl compiler around for seven years that isn't commonly used means that bug reports and fixes do not come in frequently enough to keep the perl maintainer's
attention.
The compilation speed savings you seem to be looking for are probably hard to do in a language like dynamic perl. I once heard a talk that Dan Sugalski made in which he said:
Perl is a late, late, late, late, I mean 'waiting for Godot' late, bound language.
Perl can be running its END{} blocks and still not have bound its method calls to
their classes.
(this is entirely from memory and I was probably sitting in the back of the room trying to work. I hope Dan forgives me if I misquoted him, but I think I got the general feel of the statement correct.)
A lot of the things that make perl an easy language to work in, classes with an open scope, implicit type conversion, informal class interfaces, and the like depend on the fact that decisions, when a decision has to be made, to be put off until run time. Adding a compiler doesn't change much of that.
