Re: [Chicken-janitors] #1214: Specialization on certain `or' types doesn't work

[Chicken Trac]

#1214: Specialization on certain `or' types doesn't work
--------------------------+----------------------
  Reporter:  syn          |      Owner:  evhan
      Type:  defect       |     Status:  assigned
  Priority:  minor        |  Milestone:  someday
 Component:  scrutinizer  |    Version:  4.10.x
Resolution:               |   Keywords:
--------------------------+----------------------
Changes (by evhan):

 * owner:   => evhan
 * status:  new => assigned


Old 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 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.

New 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.

--

--
Ticket URL: <http://bugs.call-cc.org/ticket/1214#comment:2>
CHICKEN Scheme <http://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.