Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: ANSI C token set (including $ and @)
Message-ID: <9470@smoke.BRL.MIL>
Date: 21 Jan 89 14:51:53 GMT
References: <11343@haddock.ima.isc.com> <1858@zell.cs.vu.nl> <9438@smoke.BRL.MIL> <511@sdrc.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <511@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes:
>But the critical point is that the $ character ISN'T in an
>identifier if the implementation is conforming: foo$bar gets
>parsed as three tokens just like foo+bar would.

It's still the case that $ is not going to appear in foo$bar
context in a strict conforming application.  I think the problem
you have in mind is that foo$bar leads to surprises if foo or
bar is a macro, just as use of EGAD when <errno.h> is included
can lead to surprises.

Perhaps the best way to implement extended identifier character
sets would be with a non-conforming mode flag to the compiler
to enable such an extension.  I can see serious problems with
use of non-Roman characters in foreign-language contexts.
What did we respond to the Japanese comment about this?