Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!.UUCP!RAM
From: RAM@.UUCP.UUCP
Newsgroups: comp.windows.x
Subject: X atoms, a poll
Message-ID: <RAM.12278759272.BABYL@>
Date: Fri, 13-Feb-87 12:59:00 EST
Article-I.D.: .RAM.12278759272.BABYL
Posted: Fri Feb 13 12:59:00 1987
Date-Received: Sat, 14-Feb-87 14:38:50 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24


I would say use underscores and single case, but I agree with Scott
that it isn't a make or break issue since an interface isomorphic to a
non-lisp system is going to be ugly anyway.  For example, in the case
of properties, you are already going to have to explicitly declare a
to-lisp translation for each property so that the system knows how to
lispify the property value.

I don't see why you say that underscores are "subject to
reinterpretation", and thus unsuitable for use in symbols.  It is true
that underscores may appear in potential numbers (which cannot be read
without escapes) but that doesn't stop you from interning them.  The
whole idea behind specifying potential numbers is that chops off a
piece of syntax for future use with the understanding that anything
else will always be symbol.

Although it would surely be amusing explaining the potential number
rules to C programmers, I believe that if you stick to legal C
identifiers, then the only way that you could come up with a potential
number is if you began the name with an underscore and followed it by
letters and digits without any two adjacent letters.  C programmers
will screw us without trying nearly that hard.

  Rob