Opened 10 years ago
Last modified 10 years ago
#1214 closed defect
Specialization on certain `or' types doesn't work — at Initial Version
| Reported by: | Moritz Heidkamp | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | someday |
| Component: | scrutinizer | Version: | 4.10.x |
| Keywords: | Cc: | ||
| Estimated difficulty: |
Description
Given a procedure foo
(: foo (* -> symbol)) (define (foo x) 'unspecialized)
and a user-defined specialization for it:
(define-specialization (foo (x fixnum)) 'fixnum)
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 forlistwill not match
null: even thoughnullis a subtype oflistand 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 anullargument, 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.
