SUBTYPEP incorrectly returns NIL, NIL in the presence of non-existent types
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Won't Fix
|
Low
|
Unassigned |
Bug Description
What I do:
(subtypep 'fake-type 'other-fake-type)
What happens:
NIL, NIL is returned.
What I expected to happen:
First of all, I'm not sure what the consequences of using such non-existent types are supposed to be. The definition of subtypep doesn't seem to tell. (I note that SUBTYPEP has "Exceptional situations: None", which I didn't expect.) However, the standard says that (typep t 'fake-type) has undefined behavior, but SBCL already throws an error for that (proving its ability to detect such invalid types)... So subtypep should be able to throw an error too. (There might be implementation or performance concerns why this isn't done?)
More importantly, the definition for SUBTYPEP says: "subtypep is permitted to return the values false and false only when at least one argument involves one of these type specifiers: and, eql, the list form of function, member, not, or, satisfies, or values. [...] One consequence of this is that if neither type-1 nor type-2 involves any of these type specifiers, then subtypep is obliged to determine the relationship accurately."
In light of this, it seems clear that the exhibited behavior is in violation of the standard.
SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux
*features*:
(:SWANK :QUICKLISP :SB-BSD-
:SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
:SB-SOURCE-
:LARGEFILE :GENCGC :STACK-
:COMPARE-
:STACK-
:STACK-
:CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-
:OS-PROVIDES-
Not sure, but needs proper consideration for sure.
SBCL considers unknown- at-the- moment types pretty much as if they were SATISFIES types involving an unknown function.
This may be a divergence, and if so it needs to be either fixed or documented (and a rationale given.) If it turns out the be allowed, it should still be documented because I don't think you're the first person to wonder about this...