[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CHAR-BIT



At the top of page 244, it says that it is an error to give this the name of a bit
that doesn't exist in a given implementation. This is a loss because it means that
users then have to
 * know which bits are supported where 
 * write code to know it.

Consider:

   (DEFUN HAS-HYPER-BIT-P (CHAR)
     #+Symbolics (CHAR-BIT CHAR :HYPER)
     #-Symbolics NIL)

This sort of definition bothers me. Even the non #'d variant:

   (DEFUN HAS-HYPER-BIT-P (CHAR)
     (IF THIS-IMPLEMENTATION-HAS-A-HYPER-BIT-P (CHAR-BIT CHAR :HYPER)))

bothers me since the compiler is no doubt going to warn me about using
CHAR-BIT with an invalid argument. I suppose I have to write:

   (DEFMACRO IF-THIS-IMPLEMENTATION-HAS-A-HYPER-BIT (&BODY FORMS)
     (IF THIS-IMPLEMENTATION-HAS-A-HYPER-BIT-P `(PROGN ,@FORMS) `NIL))

   (DEFUN HAS-HYPER-BIT-P (CHAR)
     (IF-THIS-IMPLEMENTATION-HAS-A-HYPER-BIT (CHAR-BIT CHAR :HYPER)))

to avoid that.

And what if I was wrong? What if some other implementations allow a Hyper bit
that I don't know about. eg, what if there were another LispM company besides 
Symbolics or what if the DEC VT1000 has a Hyper key? Does that mean his code
should be wrong? Isn't it reasonable for him to predicate Hyper-ness of a
character even though it will never be Hyper? 

Also, there will certainly be keyboards that can't generate a Hyper key even in 
machine implementations that could accept it; in those cases, it certainly makes
sense to ask about bits that couldn't exist. 

The point is that conceptually it makes sense to allow this and implementationally
it's possible to make these efficient. eg, (CHAR-BIT char :HYPER) can optimize to
NIL at compile time in some implementations, and it's probably ok for
(CHAR-BIT char X) to be a bit slower.

So I believe I should be able to simply do

   (CHAR-BIT CHAR :HYPER)

and reliably get NIL in implementations that do not support the Hyper key.

As to SET-CHAR-BIT, I am content to have an error generated when I try to set
a non-existent bit. This happens, I suspect, less frequently. [In fact, the only 
case I can think of where it would ever happen at all is where someone is writing
code (eg, for an editor) that offers a Hyper- escape for keyboards that can't 
generate such characters primitively.] I am willing to specially conditionalize 
such cases.

In principle, there may be implementations that don't support even the :CONTROL bit.
For the sake of such implementations, are you willing to conditionalize your
uses of (CHAR-BIT CHAR :CONTROL) in order to be able to truthfully claim portability?

-kmp