ctype
ctype copied to clipboard
s-expressionists
CL type system implementation
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...
Such as extraction various information from types (contained element type, dimensions, ranges, etc) and providing something like default value? I can certainly help with both.
For example, `(ctype:specifier-ctype '(function ((values integer))))` returns a ctype with a values type in the lambda list, which is nonsensical. It should signal a syntax error. It would probably be...
Number is NOT a subtypep of `(or real complex)`. You have your own subtypep so you probably do not care, but still informing you about this. More here: https://www.reddit.com/r/Common_Lisp/comments/nm4glc/real_and_complex_are_somehow_not_all_numbers/
Parsing
I'm more convinced that parsing and type operations can and should be separated. Parsing involves the environment and some details about how the implementation `deftype` works. Furthermore, for a more...
ansi-tests for `subtypep` and possibly `typep` would be a good start. We'd probably want to be stricter, since we'd like to do better than ANSI requires (e.g. in returning comprehensive...
```lisp (assert (ctype:ctype= (ctype:cfunction (make-instance 'ctype:lambda-list :required () :optional () :rest (ctype:bot) :keyp t :keys (list (cons 'var (ctype:specifier-ctype 'integer))) :aokp nil) (ctype:values-specifier-ctype '(values integer &rest t))) (ctype:specifier-ctype '(function (&key...
The `unparse` methods have gotten very unwieldy in a probably vain attempt to print ctypes nicely. We could just keep the original type specifiers around when ctypes are constructed from...