Path: utzoo!attcan!uunet!bfmny0!tneff From: tneff@bfmny0.UU.NET (Tom Neff) Newsgroups: comp.lang.perl Subject: p2c (was Re: a program by any other name...) Message-ID: <15329@bfmny0.UU.NET> Date: 7 Apr 90 05:30:51 GMT References: <101155@convex.convex.com> <1990Apr6.170914.8305@iwarp.intel.com> <1990Apr7.030242.367@chinet.chi.il.us> Reply-To: tneff@bfmny0.UU.NET (Tom Neff) Lines: 22 The simplest thing to do would be not to support 'do' or 'eval' in p2c. You replace standard library do's (like getopts) with a literal inclusion of the code, or else hooks to a C support library. Funny cute and clever conditional do's you just don't support. Same thing with funny cute and clever eval's that you can't program around with a different Perl algorithm. If your program HAS to have those things, you probably don't want C anyway. (There is a class of eval usage involving "which variable do I store into" etc, which is normally solved in C with pointers. Perl is so flexible it seems unlikely an automated tool could catch this and do the transformation itself, but a smart programmer could probably translate the rest of the script into C and tackle that part himself.) For me the point of p2c would be to let you use NON-obfuscated Perl as a straightforward prototyping language, then generate portable C code when you're done. For neat little filters this can result in space and time savings; for programs of all sizes, it means you can take them places Perl doesn't run. -- US out of North America, NOW!! /: Tom Neff -- Richard O'Rourke :/ tneff%bfmny0@UUNET.UU.NET