Subject: Re: [not so] basic package question
From: Erik Naggum <>
Date: Sat, 27 Apr 2002 18:21:44 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* james anderson <>
| 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

| (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: