Summary

Specialization on certain `or' types doesn't work

Metadata

Description

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.

Changes and comments

[2015-08-25 21:55:03 UTC] evhan wrote:

The same is true for compiler-typecase.

[2015-09-29 22:08:13 UTC] evhan changed status from new to assigned

[2015-09-29 22:08:13 UTC] evhan set owner to evhan

[2015-09-29 22:08:13 UTC] evhan changed description

[2015-10-30 21:19:15 UTC] sjamaan changed status from assigned to closed

[2015-10-30 21:19:15 UTC] sjamaan set resolution to fixed

[2015-10-30 21:19:15 UTC] sjamaan wrote:

Fixed with 14f6f55 and c467b40