-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect function type parsing #16
Comments
Also, as a side note -- any chance you would implement (sub)ctypep on complex function types? |
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 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 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 |
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. |
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 |
Again, sorry about the delay. I fixed the error in return types, but I haven't touched the values parsing. And I checked and 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. |
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 |
Several bugs related to this:
(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.
(values ....)
is not being parsed correctly.The text was updated successfully, but these errors were encountered: