Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.lang.perl
Subject: Re: PERL compiler ?!?
Message-ID: <1990Nov11.035903.6333@chinet.chi.il.us>
Date: 11 Nov 90 03:59:03 GMT
References: <MITCH.90Nov9124943@hq.af.mil> <1990Nov11.004221.11147@iwarp.intel.com>
Organization: Chinet - Public Access UNIX
Lines: 19

In article <1990Nov11.004221.11147@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes:

>We went through this about six months ago.  If you have power of
>"eval", you have to have an interpreter in the run-time package.  And
>since Larry goes to great pains to compile the code to an efficient
>pile-o'-bits before running it, you probably wouldn't gain much by
>turning that data structure inside-out into a bunch of procedure
>calls.  But, hey, if you've got student labor, go for it. :-)

A nice compromise would be to split the compiler and run-time code apart
and allow saving the compiled script files between runs.  Then if your
code doesn't use "eval", you never have to bring in the compiler at all
and if it does, it can just run it in another process and look at the
output file.  Even if perl weren't split into two separate programs,
systems with demand paged exectuables would get much the same effect
just by allowing the compiled script to be saved for re-execution.

Les Mikesell
  les@chinet.chi.il.us