From ljm@slac.stanford.edu Tue Mar 28 13:29:56 1995 Received: from SCSW6.SLAC.Stanford.EDU by dkuug.dk with SMTP id AA14911 (5.65c8/IDA-1.4.4j for ); Wed, 29 Mar 1995 07:27:05 +0200 Received: from [134.79.128.74] (MOZART.SLAC.Stanford.EDU) by SCSW6.SLAC.STANFORD.EDU (PMDF V4.3-10 #6987) id <01HOOMT2DX4W0037HJ@SCSW6.SLAC.STANFORD.EDU>; Tue, 28 Mar 1995 21:28:06 -0800 (PST) Date: Tue, 28 Mar 1995 21:29:56 -0800 From: ljm@slac.stanford.edu (Leonard J. Moss) Subject: Re: (SC22WG5.779) Re: CCF Proposal by David Epstein (X3J3/93-276) X-Sender: ljm@popserv To: Robert.Corbett@eng.sun.com (Robert Corbett), sc22wg5@dkuug.dk Message-Id: X-Envelope-To: sc22wg5@dkuug.dk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Charset: ASCII X-Char-Esc: 29 At 18:28 3/28/95, Robert Corbett wrote: >A couple of deficiencies of Mr Epstein's proposal are immediately obvious. >First, it needs an include facility. People using a preprocessor will >want to pick up definitions from system include files (at least). Those >definitions need to be available at the time preprocessing takes place. >Also, user-supplied defines should affect the included files. > >... I agree that an include mechanism is desireable. However, having _two_ independent include mechanisms is highly undesirable. Ideally, I would like to see CCF integrated with the compiler and acting on the source stream produced after the compiler resolves the regular FORTRAN includes. Where CCF is a separate preprocessor, it could either expand the regular Fortran INCLUDE lines itself (at the cost of preserving the line numbers), or leave it to the user to define all the CCF variables in some other fashion (e.g., via switches on the CCF command line, or by means of some sort of script to concatenate a single "configuration file" to the front of every file to be preprocessed). Since CCF does not support macro processing, or even simple text substitution, the number of CCF variables that need to be defined is likely to be small and this is not likely to be an unreasonable burden. IMO, adding a "!CCF$ INCLUDE ..." statement would be a mistake. -- Leonard J. Moss | My views don't necessarily Stanford Linear Accelerator Center | reflect those of SLAC, MS 97; P.O. Box 4349; Stanford, CA 94309 | Stanford or the DOE