- (res (any))
- (exact nil))
- (dolist (type types (values res exact))
- (when (eq type (specifier-type 'function))
- ;; KLUDGE: Deal with (and function instance), both of which
- ;; have an exact primitive type.
- (return (part-of function)))
- (multiple-value-bind (ptype ptype-exact)
- (primitive-type type)
- (when ptype-exact
- ;; Apart from the previous kludge exact primitive
- ;; types should match, if indeed there are any. It
- ;; may be that this assumption isn't really safe,
- ;; but at least we'll see what breaks. -- NS 20041104
- (aver (or (not exact) (eq ptype res)))
- (setq exact t))
- (when (or ptype-exact (and (not exact) (eq res (any))))
- ;; Try to find a narrower representation then
- ;; (any). Takes care of undecidable types in
- ;; intersections with decidable ones.
- (setq res ptype))))))
+ (res (any)))
+ ;; why NIL for the exact? Well, we assume that the
+ ;; intersection type is in fact doing something for us:
+ ;; that is, that each of the types in the intersection is
+ ;; in fact cutting off some of the type lattice. Since no
+ ;; intersection type is represented by a primitive type and
+ ;; primitive types are mutually exclusive, it follows that
+ ;; no intersection type can represent the entirety of the
+ ;; primitive type. (And NIL is the conservative answer,
+ ;; anyway). -- CSR, 2006-09-14
+ (dolist (type types (values res nil))
+ (multiple-value-bind (ptype)
+ (primitive-type type)
+ (cond
+ ;; if the result so far is (any), any improvement on
+ ;; the specificity of the primitive type is valid.
+ ((eq res (any))
+ (setq res ptype))
+ ;; if the primitive type returned is (any), the
+ ;; result so far is valid. Likewise, if the
+ ;; primitive type is the same as the result so far,
+ ;; everything is fine.
+ ((or (eq ptype (any)) (eq ptype res)))
+ ;; otherwise, we have something hairy and confusing,
+ ;; such as (and condition funcallable-instance).
+ ;; Punt.
+ (t (return (any))))))))