> Vassil Nikolov <v...@einet.bg> writes: [...] > > There is one small detail which makes the third case (with "KEYWORD") > > preferrable: if the read case is not the default uppercasing one,^1 one > > would get the wrong result with the first two cases. [...] > Well, of course then you can do (FIND-PACKAGE 'KEYWORD). > After all, if readtable case is set to not upcase, find-package has to > be in the right case, too.
That is true. A valid example would be much more convoluted.
So the only real reason to say "KEYWORD" remains avoiding the creation of unnecessary symbols.
Let me just note that if the function name is not in the right case, it is easier to find the problem than for the datum passed as an argument, and one can also reasonably expect a warning as early as compile time.
> But I wouldn't program defensively about this. After all, no one > should ever surprise anyone else with a change to the case. That is > always a hostile act. Really no different than making the letter "A" > a readmacro character. Programs have to assume the syntax they are > written in will not be changed without warning.
Yes. In fact, truly defensive (read: paranoid) programming would be
(|CL|:|FIND-PACKAGE| '|KEYWORD|)
(still defenseless against changes to the readtable...).
* Lieven Marchand <m...@bewoner.dma.be> | A way to avoid this is using a true string as in (find-package "B"). | Some people don't like the upper case you then have to use and so a third | way is to use symbols in the keyword package as in (find-package :b).
I don't like to type upper-case, don't like to use symbols (including keywords), and don't want to change my Lisp to use lower-case internally, so I set up a reader macro that reads the symbol-name the same way the reader does, but only the name which would have been given to INTERN. in Allegro CL, this name is returned by EXCL::READ-EXTENDED-TOKEN. as in: (find-package #"whatever").
this function will parse single and multiple escape, too, of course, but using both multiple escape when the idea is to avoid using the string seems silly to me, so I don't recommend #"|GetRandomWindowsCruft|" over "GetRandomWindowsCruft", but then again, I don't recommend that case- sensitive symbols be used in Lisp in the first place -- use a more Lispy name: get-random-windows-cruft.
(in-package :excl)
(loop with readtables = (get-objects 11) for i from 1 to (aref readtables 0) for *readtable* = (aref readtables i) when (readtable-dispatch-tables *readtable*) do ;; reader for symbol names that does case conversion according to the rest of the symbol reader. ;; thanks to John K. Foderaro for the pointer. (set-dispatch-macro-character #\# #\" (named-function symbol-namestring-reader (lambda (stream character prefix) (declare (ignore prefix)) (prog1 (read-extended-token stream) (unless (char= character (read-char stream)) (internal-reader-error stream "invalid symbol-namestring syntax")))))))
* Kent M Pitman <pit...@world.std.com> | I'd be happier with #, than #.
but #, is history, now, effectively replaced by LOAD-TIME-VALUE, which means it's probably smart to make a reader macro that re-introduces #, as a LOAD-TIME-VALUE wrapper around the following form, as ' does for QUOTE.
Erik Naggum <e...@naggum.no> writes: > * Kent M Pitman <pit...@world.std.com> > | I'd be happier with #, than #.
> but #, is history, now, effectively replaced by LOAD-TIME-VALUE, which > means it's probably smart to make a reader macro that re-introduces #, as > a LOAD-TIME-VALUE wrapper around the following form, as ' does for QUOTE.
Yes, that sounds right. I think we talked about it at the time, and people weren't that strong on it, but the times might have changed.
(There's certainly precedent for resurrecting things in repaired fashion after a calculated period of non-use. That's how we "fixed" CATCH. In Maclisp, now decades ago, it used to not evaluate its tag argument. We went through many years in Maclisp of using a *CATCH that did evaluate its argument, and phased out CATCH gradually at that time. CL felt free to reintroduced CATCH with approximately the *CATCH semantics (modulo more compulsive tweaking due to multiple values) without fear of incompatibility with CATCH since the original CATCH had effectively been deprecated for years.)
