why has Cray dropped CPP support from cf77?

[Peter Klausler]

In article <1991Feb19.162007.28774 at ncsa.uiuc.edu> hirchert at ncsa.uiuc.edu (Kurt Hirchert) writes:
>In article <1298 at red8.qtp.ufl.edu> bernhold at qtp.ufl.edu (David E. Bernholdt) writes:
>>
>>The latest release of cf77 no longer supports automaticly running .F
>>files through CPP before compiling them.  This move seems to be a step
>>backward from the what I think is a _very_ useful feature common to
>>_many_ unix-based fortran implementations.  Does anyone know why they
>>did it?
>
>I don't know, but I could guess.  As I understand it, the standard C compiler
>(scc) doesn't use cpp, but does preprocessing internally, instead.  Under
>Unicos 6.0, scc becomes the default cc, and the previous cc becomes pcc,
>presumably with the intention of eventually eliminating support for pcc.
>If cpp is seen as being part of a product that is no longer going to be
>supported, then I can see why they would not want to continue using it in
>one of their other supported products.
>
>Now, scc has switches so that it can be used as a replacement for cpp, so
>I suppose you could lobby with CRI to run .F files through that, but I can
>imagine the confusion when the documentation for cf77 says that under some
>circumstances it runs your Fortran source through cc!

It would appear infeasible to use an ANSI Standard C preprocessor or
preprocessing phase as a general cpp-like macro processor for Fortran or CAL.
Why? ANS C preprocessing is token-based, not character-based, and applies ANS C
tokenization to its input. This works fine for C, of course, but has some
trouble with Hollerith data, CAL's odd O' and X' syntax, apostrophes in Fortran
comments, etc.

Beats me how we'll ever get rid of /lib/cpp, or if we should even want to do so.