From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!ossa.telenet-ops.be!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: [not so] basic package question References: <3CC0C3D8.C76B0F00@interaccess.com> <4lmbi5q1f.fsf@beta.franz.com> <3CC7D09E.42A2AC89@setf.de> <3CC860AB.547EA4A5@setf.de> <4ofg7cw70.fsf@beta.franz.com> <3CC9558C.945C1E89@setf.de> Mail-Copies-To: never From: Erik Naggum Message-ID: <3228855740453508@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Apr 2002 00:22:20 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader3.kpnqwest.net 1019866940 193.71.199.50 (Sat, 27 Apr 2002 02:22:20 MET DST) NNTP-Posting-Date: Sat, 27 Apr 2002 02:22:20 MET DST Xref: archiver1.google.com comp.lang.lisp:32373 * james anderson | the responses have convinced me that matters of symbol name case are not | trivial and that i should presume as little as possible about internal | symbol representation. Well, while this is a valid conclusion, I think you should just know that unless you work _very_ hard to make it otherwise, the standard mandates upper-case internal symbol names, and you should _never_ expect to find a symbol in all lower-case in the package named "COMMON-LISP". We have no mechanism that could support symbol forwarding in Common Lisp, although it could have been a good thing to have, such that you could rename symbols upon import to a new package. Such a feature could have been used to make lower-case "clones" of symbols. (One _could_ hack the package hashtables to fake this effort.) | the problematic program generates marshalling functions and macros from | document type definitions and schema. these functions include numerous | pairs, one a macro and one a generic function, which produce an encoded | markup stream. they differ primarily in that the macro version makes | more decions at compile time about what and how to encode things. i had | been generating the respective symbols in the same package, inverting the | case of one or the other of them in accord with readtable case. i | believe that method is portable. despite that, it is not as robust as it | could be. Well, it is. The readtable case is not where you want to look at this. | it would be better to allow one to specify destination packages and cases | for the respective symbols when the marshalling functions are generated | from the definitions. the default settings would be carried over from | readtable case, but it would be possible to accommodate other approaches. "Destination packages"? Hm. This weird expression _may_ indicate a lack of understanding of the package system. I hope you are aware that the way to control the package into which the reader will intern symbols when they have no package qualification is controlled by the value of the special variable *package*. If you are not using the reader to read Common Lisp code with symbols that (may) live in the common-lisp package, you may use any case you want for your own symbols and adjust the readtable-case so it fits your needs. There is nothing in Common Lisp that requires your own symbols to be in upper-case, it is just massively convenient when also working with symbols in the common-lisp package. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief. Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg