Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!eneevax!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: Stop adding types, Let's remove Trigraphs instead!!
Message-ID: <5899@brl-smoke.ARPA>
Date: Thu, 28-May-87 00:45:38 EDT
Article-I.D.: brl-smok.5899
Posted: Thu May 28 00:45:38 1987
Date-Received: Sat, 30-May-87 11:32:09 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <879@eneevax.UUCP> <6603@amdahl.amdahl.com> <4051@teddy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <4051@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>That may be, but they are still UGLY!  The proposed standard says that
>a conforming C implementation must be able to accept source code with
>trigraphs in it:  I would rather see it be optional, or implemented as
>a pre-processer external to the compiler itself.

Absolutely; such issues are properly in the domain of the programming
environment, not the language.  My guess is that, unless there is
strong sentiment expressed FOR trigraphs at the Paris meeting,
trigraphs stand a good chance of being removed from the final ANS.

Incidentally, I've threatened to publish a portable (ANSI C!)
preprocessor that will process portable ANSI C source text files and
strip #pragma directives and substitute normal C source code
characters for trigraphs.  I'm waiting to see whether it's going to
be necessary.