id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	difficulty
1214	Specialization on certain `or' types doesn't work	Moritz Heidkamp	evhan	"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."	defect	closed	minor	someday	scrutinizer	4.10.x	fixed