Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv
From: emv@math.lsa.umich.edu (Edward Vielmetti)
Newsgroups: comp.lang.perl
Subject: Re: p2c (was Re: a program by any other name...)
Message-ID: <EMV.90Apr7123014@duby.math.lsa.umich.edu>
Date: 7 Apr 90 16:30:14 GMT
References: <101155@convex.convex.com> <BLARSEN.90Apr6095532@spider.uio.no>
	<1990Apr6.170914.8305@iwarp.intel.com>
	<1990Apr7.030242.367@chinet.chi.il.us> <15329@bfmny0.UU.NET>
Sender: news@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor MI.
Lines: 18
In-reply-to: tneff@bfmny0.UU.NET's message of 7 Apr 90 05:30:51 GMT

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.edu