Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!wa4mei!holos0!lbr From: lbr@holos0.uucp (Len Reed) Newsgroups: comp.lang.perl Subject: Re: PERL compiler ?!? Message-ID: <1990Nov15.145238.3531@holos0.uucp> Date: 15 Nov 90 14:52:38 GMT References: <1990Nov11.004221.11147@iwarp.intel.com> <1990Nov11.035903.6333@chinet.chi.il.us> Organization: Holos Software, Inc., Atlanta, GA Lines: 30 Eepeep: WHAT, Noname? In article <1990Nov11.035903.6333@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >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.... >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.... I was hoping to break the MS-DOS version of perl into overlays along this line. I figured that it would be nice if one overlay could handle the compilation and the other execution. An eval-laden script might thrash, but this could save a lot of memory for most other scripts. Alas, I couldn't come up with a useful partitioning of the .c files. I've used a razor, not a hatchet, on Larry's code. (The big changes were in the msdos subdirectory.) Maybe I'll do this now that the functionality of the MS-DOS port is better. As much as I've worked on this, though, I've stayed on the periperhy of perl; I'm not very clear on most of its internals. BTW, I'll be sending my MSDOS patches to Larry today. -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr