Re: Life without eval
/--- On Fri, Aug 04, 2000 at 05:58:44PM +0100, Piers Cawley wrote: | > At 02:31 PM 8/4/00 +0200, dLux wrote: | > > My suggestion is: declare "eval $scalar" as a bad guy. | > It's not just string eval. It's also do FILE and require. | > It's a powerful construct, though, and I wouldn't declare it as | > evil. | > Possibly as "unimplemented on some platforms (read: palm)" or | > "The | > optimizer loathes eval/require/do FILE after BEGIN time with a | > passion you | > couldn't imagine", but not evil. | | But, if the FILE it's being 'do'ne to is actually precompiled | bytecode... \--- I rethought this thinggy, and (because of the config files or other "do" and "require") the compiler needs to be available, but I think the best place is in the libperl.so (or libperl.prc in palm for example). It could make a compiled file if necessary (and have access to the file) like python does, and only called when a non-compiled code is referenced (like eval). But module writers should minimize the usage of the eval construct... dLux -- == Whip me. Beat me. Make me maintain AIX ==
Re: Life without eval
At 01:30 AM 8/5/00 +0900, Simon Cozens wrote: >On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote: > > At 02:31 PM 8/4/00 +0200, dLux wrote: > > > My suggestion is: declare "eval $scalar" as a bad guy. > > > > It's not just string eval. It's also do FILE and require. > >Which you need at runtime, even in compiled code, to run external >configuration files written in Perl. Oops! Yup, oops indeed. OTOH, if we do bytecompiled files (like emacs .el/elc stuff), it's not a huge oops, since we may well be able to load in the bytecompiled version. And it does mean that folks writing perl code to run on palms and other small devices might want a Plan B to save config files off. Which is just fine, TMTOWTDI. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Life without eval
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 02:31 PM 8/4/00 +0200, dLux wrote: > > My suggestion is: declare "eval $scalar" as a bad guy. > > It's not just string eval. It's also do FILE and require. > > It's a powerful construct, though, and I wouldn't declare it as evil. > Possibly as "unimplemented on some platforms (read: palm)" or "The > optimizer loathes eval/require/do FILE after BEGIN time with a passion you > couldn't imagine", but not evil. But, if the FILE it's being 'do'ne to is actually precompiled bytecode... -- Piers
Re: Life without eval
On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote: > At 02:31 PM 8/4/00 +0200, dLux wrote: > > My suggestion is: declare "eval $scalar" as a bad guy. > > It's not just string eval. It's also do FILE and require. Which you need at runtime, even in compiled code, to run external configuration files written in Perl. Oops! -- Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car.
Re: Life without eval
At 02:31 PM 8/4/00 +0200, dLux wrote: > My suggestion is: declare "eval $scalar" as a bad guy. It's not just string eval. It's also do FILE and require. It's a powerful construct, though, and I wouldn't declare it as evil. Possibly as "unimplemented on some platforms (read: palm)" or "The optimizer loathes eval/require/do FILE after BEGIN time with a passion you couldn't imagine", but not evil. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Life without eval
>Hello! > I am thinking about the perl compiler, and I thought if somebody >avoid using the "eval $scalar", the compiled code (perl to C >compiled code) may not contain a full perl interpreter. If it is the >case, we must say to any module developer: Don't use "eval $scalar"! >This syntax should remain for small dirty scripts. > Most of the work should be done with "no strict" mode. > My suggestion is: declare "eval $scalar" as a bad guy. > Comments? (I may write an RFC if it worth...) eval is very powerful. Don't knock it. Remember the beauty of the read/eval/print loop from your first lisp class. --tom
