From: Nikodemus Siivola <nikodemus@ra...>  20120603 10:18:08

On 1 June 2012 04:20, Tomohiro Matsuyama <tomo@...> wrote: > I have found some odd subtypep behavior on function type. > > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (fixnum) integer)) > T > T > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (integer) integer)) > T > T > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (bit) integer)) > NIL > T > > As you may know, function parameters should be contravariant, meaning if we have a>b <: a'>b, then a' <: a must hold. So last two statement could be said wrong, or at least the second value should be false. I don't follow. In CL, and SBCL specifically covariance seems exactly right to me. Can you unpack your reasoning a little? If I replace a (function (integer) integer) with (function (fixnum) fixnum) any callsite that relied on the previous definition is still safe: they may now get an error due to narrowing of the type, but any typebased reasoning the system did is still valid. Ie. "if F returns, the thing it returns must be an integer". Of course CLHS SUBTYPEP doesn't specify SUBTYPEP properly  so perhaps we should return NIL, NIL in case of both covariance and contravariance, and implement FSUBTYPEP (or possibly FTYPESCOVARIANTP and FTYPESCONTRAVARIANTP.) Cheers,  Nikodemus 