Incorrect function type parsing

[commander-trashdin]

Several bugs related to this:

1. (ctype:specifier-ctype '(function (t) (values t &optional))) and (ctype:specifier-ctype '(function (&optional t) (values t &optional)))
   seem to both result in a function with 1 optional argument of type t !in return type!, which is incorrect -- in first case it should obviously be a required argument.
2. Actually the examples above would not even compile (I have a local patch for that), since function return type declared via (values ....) is not being parsed correctly.

[commander-trashdin]

Also, as a side note -- any chance you would implement (sub)ctypep on complex function types?

[Bike]

It might take me a few days to get to this bug - I just finished up a big project we've been doing at work and I have a bunch of stuff to catch up on.

You are right that these types are currently not accepted - that's definitely a bug. If you submit your patch as a PR I can merge it.

As for your actual complaint, that has to do with how values types are defined in the standard. By definition, using a function type is like using the around calls to the function, and the applies a degree of fuzziness to values types that makes it, by my reading, impossible to declare that a form returns at least one value, for example. I don't think this is great, but that's what the standard says as far as I can tell.

That said, it might be a good idea for ctype to use a stricter interpretation of values types. It already does so internally, but when parsing it applies the "fuzziness". I could rearrange things so that the fuzziness is left up to the client and not applied by ctype itself, or put in a *strict-values-type-parsing* control variable or something.

As for subctypep on function types, I would need a good idea of how to do it. The standard doesn't really define any notion of subtyping for them. Also, function types are weird in that like I said, they technically apply to calls to the function rather than the function object itself, which is pretty alien to the notion of subtyping at all, really.

The main thing is that the usual theory of types makes function types contravariant in their parameters: essentially (function (integer)) is a subtype of (function (fixnum)) and not the other way around. Intuitively, any function that accepts integers obviously also accepts fixnums, whereas a function that accepts fixnums may or may not accept other integers, so the set of (function (fixnum)) objects is strictly larger. This makes sense to me, but I don't know how well it meshes with the standard's view. SBCL, which has probably the most sophisticated subtypep among Lisp implementations, does not make function types contravariant in parameters. Do you have any thoughts on this? I don't know what use cases for this are like.

[commander-trashdin]

Well the use case for (sub)ctypep working on function is to then be able to use them in HOFs in my library as well as just put them into slots of objects (because my accessors are polymorphic). I understand that function types are contravariant, but also there's an issue of very complicated lambda lists, how the subtyping would interact with &key and &rest args -- that's really a big thing. But we need it, I'll be glad to be of any help.

[Bike]

So contravariance is okay with you? Alright then.

I had to refresh my memory here, but it looks like I already went rather a ways into implementing this in cfunction.lisp. I will have to check how well it works after fixing the values parsing stuff, and there are some obvious weak points (e.g. it totally gives up if &key is present).

[Bike]

Again, sorry about the delay. I fixed the error in return types, but I haven't touched the values parsing. And I checked and subctypep does work on function ctypes, although with covariant parameters.

I would also like to draw your attention to another library, put out by heisig recently: typo. It is an implementation of the type system, but geared for efficiency and type inference, rather than correctness which is my main goal here. May be useful to you.

[commander-trashdin]

Thank you so much (for giving the link as well). We might switch to our own version of type system, found here https://github.com/digikar99/extensible-compound-types