Note that the manual says (I emphasised some words)
- Variable: BOTHCASES
[...]
This is implemented as follows: If the symbol is being encountered
for the first time, if the upper case version is in the package
AND HAS A NONTRIVIAL FUNCTION OR PROPERTY LIST, then the upper
case symbol is used, and it is recorded on the mixed case one,
that the upper case should be used in future. If a symbol is
already in the package then it is just used.
This, however, is not the way things actually work. For example, $Y1
has no properties or definitions whatsoever:
(C1) properties(Y1);
(D1) []
(C2) :lisp(symbol-plist '$y1)
NIL
(C2) :lisp(describe '$y1)
$Y1 is the symbol $Y1, lies in #<PACKAGE MAXIMA>, is accessible in the package
MAXIMA.
#<PACKAGE MAXIMA> is the package named MAXIMA. It has the nicknames MACSYMA,
CL-MAXIMA, CL-MACSYMA.
It imports the external symbols of the packages SLOOP, COMMON-LISP, EXT and
exports no symbols, but no package uses these exports.
Yet ...
(C2) y1;
(D2) Y1
(C3) :lisp(symbol-plist '|$y1|)
(UPCASE $Y1)
(C3)
The reason seems to be a trivial logical bug in BOTHCASE-IMPLODE. I
propose the following patch.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** commac.lisp.orig Wed Aug 28 19:46:08 2002
--- commac.lisp Wed Aug 28 19:28:29 2002
***************
*** 740,747 ****
(symup there)
(implode1 lis t)
! (cond ((and there (or
! ;; not single symbols
! (cddr lis)
! (fboundp symup) (symbol-plist symup)))
(setf (get sym 'upcase) symup)
--- 740,747 ----
(symup there)
(implode1 lis t)
! (cond ((and there
! ;; not single letter named symbols
! (cddr lis)
! (or (fboundp symup) (symbol-plist symup)))
(setf (get sym 'upcase) symup)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, we have, e.g.,
(C1) a*b*c*d*e*f;
(D1) a b c d e f
(C2) aa*bb*cc*dd*ff;
(D2) aa bb cc dd ff
(C3) y0*y1*y2*y3*y4*y5*y6;
(D3) y0 y1 y2 y3 y4 y5 y6
Note that
(C4) g0*g1*g2*g3;
(D4) G0 G1 g2 g3
(C5) map('properties,[g0,g1,g2,g3]);
(D5) [[System Function], [System Function], [], []]
(C6)
Note that this needs further testing, of course.
Wolfgang
--
wjenkner@inode.at