tneff@bfmny0.UU.NET (Tom Neff) (04/07/90)
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.NETemv@math.lsa.umich.edu (Edward Vielmetti) (04/07/90)
In article <15329@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
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.
Rip out features, eh? You're no fun.
I've thought about this too, in the guise of "ANSI Perl" -- trim out
at some expense the difficult parts of the language, and specify it
to the point where you could contemplate either turning it into C
or doing an indepedent implementation.
--Ed
Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edutneff@bfmny0.UU.NET (Tom Neff) (04/10/90)
In article <EMV.90Apr7123014@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >I've thought about this too, in the guise of "ANSI Perl" ... Oooh, I like that. ANSI Perl, with prototypes. associative sub mysub(string $a, number array @b) { local volatile (*hardware_reg) = 0x00034; ... } system qq|perl -e 'system qq!echo Just another ANSI Perl hacker,!'| -- 'We have luck only with women -- not spacecraft!' \\ Tom Neff -- R. Kremnev, builder of failed Soviet FOBOS probes // tneff@bfmny0.UU.NET
rsalz@bbn.com (Rich Salz) (04/13/90)
The name "p2c" has been "taken" by the Pascal to C compiler that recently appeared in comp.sources.unix. PCC, on the other hand, would make a fine name for the Perl to C Compiler program... -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
marc@athena.mit.edu (04/13/90)
|> The name "p2c" has been "taken" by the Pascal to C compiler that recently |> appeared in comp.sources.unix. PCC, on the other hand, would make a fine |> name for the Perl to C Compiler program... Nope. pcc is the name of one of the vax compilers we have here. I propose pl2c, for when this program isn't vaporware anymore :-) Marc
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (04/13/90)
The name of it might well be perl -c. You could almost pipe the output of perl -D1024 to a code generator. Spitting out C code isn't the hard part. The hard part is writing the library to go with it... The runtime system of perl 3.0 is much closer to what you'd need than 2.0 was, but it's not all the way there yet. This was part of the motivation for going to something more resembling a stack machine internally. I know, we could name it "pc", and offend the Pascallers, the radicals and IBM all at once. Larry
ehrlich@cs.psu.edu (Daniel Ehrlich) (04/14/90)
In article <7763@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
Larry> I know, we could name it "pc", and offend the Pascallers, the radicals
Larry> and IBM all at once.
If you really want to get IBM upset, why not call it pl/c? Of course we
would have to drop the '/' from the name to make UNIX happy. :-)
--
Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176