He could use the 'definitely-p' return value of SUBTYPEP on the type that he wants to print to guess whether it is per se never the right type, or only in this case not the right type. The two messages could be distinguished by use "...but not a..." versus " ... which is not a ..."
- FOO is a FIXNUM which is not a LIST.
- FOO is a CONS but not a (CONS blah)

My eyes really struggle with the parenthetical form: "FOO (which is a (integer hugeval)) is ..."  
This is not a user-friendly sentence.


On Wed, Apr 2, 2014 at 9:02 AM, Paul Khuong <pkhuong@gmail.com> wrote:
Douglas Katzman wrote:
>
On Mon, Mar 31, 2014 at 12:37 AM, Krzysztof Drewniak
<krzysdrewniak@gmail.com <mailto:krzysdrewniak@gmail.com>> wrote:

    During February's code freeze, I submitted some patches to SBCL. The
    first is an improvement to the reporting of type-errors, which can be
    found at https://bugs.launchpad.net/sbcl/+bug/777346 . The second patch,
>

> TYPE-OF is sometimes going to be less aesthetic than you'd like.
> e.g. (TYPE-OF (ASH 1 70)) => (INTEGER 4611686018427387904)
> instead of INTEGER or BIGNUM
>
> Also may I suggest eliminating the parenthetical remark in the message
> and just say:
> "The value FOO is of type X but should be of type Y"

I think the bikeshed should be red.

I'll also note that TYPE-OF and CLASS-OF could both lead to issues like
"The value [...] is of type CONS, but should be of type (CONS NIL ...),"
which is less than enlightening (for two reasons).  Just to keep things as clear as possible, I'd prefer moving TYPE-OF/CLASS-OF info out of the main error message.

On the other hand, perhaps blue is a more appropriate colour… This requires more thought ;)

Paul