search

sbcl / specializable

generalized specializers work
13 stars 2 forks source link

can't find type for specializer #6

Closed scymtym closed 10 years ago

scymtym commented 10 years ago

When methods with extended specializers are compiled, a style-warning like the following is signalled:

style-warning:
  can't find type for specializer (ACCEPT "image/webp") in
  SB-PCL::PARAMETER-SPECIALIZER-DECLARATION-IN-DEFMETHOD.

Fixing this probably requires further changes in PCL.

csrhodes commented 10 years ago

Jan Moringen notifications@github.com writes:

Fixing this probably requires further changes in PCL.

A first cut would probably be a specializer-type-specifier protocol function. But it's not totally straightforward, because the specializers and the objects that they specialize to are not directly aligned any more -- case in point being the accept specializer, which is explicitly extensible by adding extra methods on specializer-accepts-generalizer-p and specializer-accepts-p. It would be tempting for the accept specializer to generate something like (or string tbnl:request) but since another web server implementor can come along and define their methods that doesn't work in general.

Of course, arguably the style-warning is bogus. But it would be nice to support as much of an automatic type declaration in methods as we can...

scymtym commented 10 years ago

but since another web server implementor can come along and define their methods that doesn't work in general.

Is it possible to regenerate such type declarations in methods when aspects (such as added specializer-accepts-generalizer-p and specializer-accepts-p methods) of a specializer change? Otherwise, this approach seems impossible since specializers could change after methods have already been defined making the type declarations in these existing methods retroactively inconsistent.

csrhodes commented 10 years ago

Jan Moringen notifications@github.com writes:

Is it possible to regenerate such type declarations in methods when aspects (such as added specializer-accepts-generalizer-p and specializer-accepts-p` methods) of a specializer change? Otherwise, this approach seems impossible since specializers could change after methods have already been defined making the type declarations in these existing methods retroactively inconsistent.

In principle, yes: the dependent protocol (add-dependent, remove-dependent, update-dependent) should be able to catch adddition of methods and propagate the information to affected generic functions. In practice this is possibly beyond messy.

It might be that for accept specializers the only correct declaration is (satisfies accept-specializer-accepts-generalizer-p) in any case, which would at least not cause any problems from eager type inference :)