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

TYPEP and arrays of (SATISFIES F)



    Date: Mon, 18 Nov 85 16:35 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    Bob Rorschach has raised the following question:  what is the
    result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
    supposed to be?  Consider these special cases:

	    (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER)
		   '(ARRAY (SATISFIES FIXNUMP) (10)))

	    (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM)
		   '(ARRAY (SATISFIES FIXNUMP) (10)))

    We can easily dismiss the first case, because clearly an array
    specialized to hold integers is not necessarily the same as one
    specialized to hold fixnums.  The second is more difficult.  It happens
    to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type
    specifiers, but in many implementations SUBTYPEP cannot discern this
    fact (and indeed is not required to).

    When TYPEP sees a plain old SATISFIES specifier, it can just call the
    function, but not so when it is the element type of an ARRAY specifier.

Returning NIL for (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
seems consistent with the discussion on page 45 of the manual.
Referring to the last line on that page, in an implementation without a
specialized array type for elements of type (SATISFIES F), no object
can pass that test.

I guess it's still an open question whether every implementation should
be required to return T for (EQUAL-TYPEP 'FIXNUM '(SATISFIES FIXNUMP))
and hence T for (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE 'FIXNUM)
		       '(ARRAY (SATISFIES FIXNUMP) (10))).
Yes, I know EQUAL-TYPEP is not a standard Common Lisp function, but I
think you get what I mean by it.  I don't think it would be a good idea
to require this, because you quickly open the door to questions like
"well, what about (SATISFIES SMALL-INTEGER-P) where somewhere in the
program it says (DEFUN SMALL-INTEGER-P (X) (FIXNUMP X))".

    One way out (proposed language change) is to define TYPEP to be like
    SUBTYPEP, in that it returns two values; if the first value is NIL, the
    second value says whether that's a "no" or a "maybe".  So for the
    first special case above TYPE would return either NIL T or NIL NIL,
    depending on the cleverness of the implementation, and for the second
    special case would return either NIL NIL or T T.

I don't think we need to change the language.