Subject: Re: [not so] basic package question From: Erik Naggum <erik@naggum.net> Date: Sat, 27 Apr 2002 18:21:44 GMT Newsgroups: comp.lang.lisp Message-ID: <3228920503727600@naggum.net> * james anderson <james.anderson@setf.de> | i am not concerned directly with symbols in the "COMMON-LISP" package. i | am concerned that, when a program generation utility creates symbols in | other packages, it do so in a way which accommodates a similar | expectation with respect to symbols in user packages, but does not fail | if the expectation is not met. I need to sort out a few things to make sure I understand what you are talking about. (1) The expectations you want met are not simply that symbols in the common-lisp package are all upper-case and that the reader and printer may produce other cases. If it were, I would conclude that you would have no problem at all since you control the reader and printer. But you give contradicting information to this position, i.e., you continue to have problems. (2) If the expectation is not met, the only way that could happen as I see your situation is precisely if the symbols in the common-lisp package were not all upper-case. You appear to claim that this is not the problem. (3) I sense a confusion in how you believe the reader and printer control variables affect the reading and printing of symbols. This sense is strongly reinforced by the fact that you neglect to tell us what your settings are. | and generated code which included things roughly like this Is this output from something? The reason I ask is that it appears more than unlikely that either of {xmlns}||, {}id, {}dir, {xml}lang, or {}lang would survive a printer that would both need to write |html| and also be happy with :use and :nicknames. | second, select a case for the symbol name: | an attribute name is transformed or preserved in manner consistent with | readtable case Why? The readtable-case is completely irrelevant to you. It concerns the mapping from input string to symbol name, but if this is SGML, you already know that the names are case-insensitive and you can canonicalize any way _you_ want, or if this is XML, you already know that the names are case-sensitive, so you should perform no transformations at all. | a function name is also transformed or preserved in a manner consistent | with readtable case | a macro name is transformed so as to be the opposite case of the | function name. This part is _really_ weird. The macro appears to be a completely useless massive complication of the whole node creation process. Would you call it on its own? Why a macro in the first place? Why make a new macro for each element when one can do for all? The whole point of the macro seems to be to convert an argument property list to an association list where all properties with a nil (= #IMPLIED?) value are removed while converting from a keyword to some weird internal symbol. This appears to me to be an excellent case for data-driven programming, not code-driven. | (that this fails where the document definition includes mixed case name | is another problem.) Well, it is a pretty strong indicator that you screwed up the design. | i did not want to use the reader. i suppose, since the names are | produced by parsing a document definition and should be fairly safe, | that concern may be unwarranted. If this is so, where does the reader come in at all? /// -- 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