RAM@.UUCP.UUCP (02/13/87)
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
Fahlman@C.CS.CMU.EDU.UUCP (02/13/87)
So the C symbols named "BitMap",
"PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
":strikeoutascent". That's a bit ugly, but workable ...
An alternative approach is to automatically insert a hyphen whenever the
C version has an upper-case character that is not at the start of the
word...
The first approach is not only ugly, but doesn't work, and I'm not sure
the second is reversible in the sense I had in mind. Note there is no
static interface between C and Lisp here, as there is in Matchmaker.
When a Lisp programmer wants to store a property, s/he doesn't want to
have to declare a binding to some C programmer's naming convention; the
whole point is to reduce the burden, not increase it. When reading a
list of window properties out of a server, you don't know what language
created them. For an automatic keyword<->atom mapping to work, every
distinct X atom must have a distinct Lisp keyword, and which also means
every distinct Lisp keyword must have a distinct X atom.
I don't understand this. Why does it matter whether the interface is
static or dynamic? When a new "atom" is created, both the Lisp and C
spellings are registered in a hash table somewhere. (Under either of my
proposals, you could register the C spelling and generate the Lisp
spelling automatically from it.) In a Lisp program you will always see
the Lisp version; in a C program, you will always see the C version. If
an "atom" is passed across the Lisp-to-C interface, part of that process
is name-conversion of any atoms.
Are you suggesting that programmers will want to make up new atom-names
on the fly and then pass them back and forth between Lisp and C without
first registering these atoms somewhere? If atoms must be registered
with C (in order to be assigned a canonical identifier), the Lisp
version of the name can be created and registered at that time.
As seen from the Lisp side, it would be something like
(register-x-atom "FooBar" "BiteTheBaggie" "FlyingWombat")
=> (:foobar :bitethebaggie :flyingwombat)
(call-some-x-routine :foobar :bitethebaggie)
=> :flyingwombat
... or ...
(register-x-atom "FooBar" "BiteTheBaggie" "FlyingWombat")
=> (:foo-bar :bite-the-baggie :flying-wombat)
(call-some-x-routine :foo-bar :bite-the-baggie)
=> :flying-wombat
-- ScottMoon@STONY-BROOK.SCRC.Symbolics.COM.UUCP (02/13/87)
I don't see any strong reason to think that using Lisp keywords to represent X atoms would be more efficient or more desirable than using Lisp strings. There is a hash-table-based translation between the Lisp and X worlds in either case. If you use strings, you don't have to worry about mapping between two different casing/punctuating conventions.
RICHER@SUMEX-AIM.STANFORD.EDU.UUCP (02/14/87)
I think a lot of people would agree with me that it's a pain for things to be case-sensitive. For example, I would want to be able to use BITMAP, bitmap, bitMap, BitMap, etc. interchangeably. It's nice to be able to use mixed-case for the purposes of reading but I find it difficult to remember one exact way to type a string unless you have strict conventions. Even so typos will kill you. As far as the hyphen-underscore (or hyphen_underscore in C) issue goes, I don't know what you should do except to say that the design of X should be general and flexible enough to accomodate the arbitrary conventions of different languages. As long as the scheme is transparent to most programmers I think a scheme would be satisfactory from an application programmer interface point of view. So I'll leave it to the Xperts as to what is best from a lower-level point of view. mark mark `< -------