Specialization on certain `or' types doesn't work

[Moritz Heidkamp]

Given a procedure foo

(: foo (* -> symbol))

(define (foo x)
  'unspecialized)

and a user-defined specialization for it:

(define-specialization (foo (x number))
  'number)

We know that this will never specialize due to "exact" argument type matching as described in the documentation for define-specialization:

Note that the matching of argument types is done "exactly". This means,
for example, that an argument type specialized for list will not match
null: even though null is a subtype of list and will match during
normal flow-analysis, we want to be able to control what happens when a
procedure is called with exactly with a list argument. To handle the case
when it is called with a null argument, define another specialization for
exactly that type or use an (or ...) type-specifier.

Following this suggestion we get a specialization like this:

(define-specialization (foo (x (or fixnum float)))
  'number)

However, in this specific case, the specialization will still never be applied because the specializer will "simplify" the (or fixnum float) expression to number before specialization, see line 1266 at c8d9cd2 in scrutinizer.scm:

((lset= eq? '(fixnum float) ts) 'number)

The same will happen for (or true false) => boolean.

It's unclear to me whether this is a bug. Also, I wonder whether it wouldn't make more sense to be able to specialize non-exactly. It certainly seems to have its uses.

[evhan]

The same is true for compiler-typecase.