Our great sponsors
-
cl-form-types
Library for determining the types of Common Lisp forms based on information stored in the environment.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
polymorphic-functions
A function type to dispatch on types instead of classes with partial support for dispatching on optional and keyword argument types.
-
coalton
Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
lisp-interface-library
LIL: abstract interfaces and supporting concrete data-structures in Common Lisp
Anyway, this library is inspired by https://github.com/alex-gutev/generic-cl and provides polymorphic versions of many common standard functions based on types. For example, now `>` and `<` work on characters and strings as well, and `at` is a universal by-key accessor for all data structures (`aref` + `nth` + `gethash` + some more). It also tries to be as strictly typed as possible, resulting in compile-time errors/warnings in case types are mismatched. Types do not always need to be declared, they can be inferred thanks to excellent https://github.com/alex-gutev/cl-form-types by Alex Gutev. Besides that it includes a collection of useful macros for more "typey" style of coding as well as several data structures I consider missing from the standard. The structures are templated -- which means there's a structure type generated for each contained element-type.
Anyway, this library is inspired by https://github.com/alex-gutev/generic-cl and provides polymorphic versions of many common standard functions based on types. For example, now `>` and `<` work on characters and strings as well, and `at` is a universal by-key accessor for all data structures (`aref` + `nth` + `gethash` + some more). It also tries to be as strictly typed as possible, resulting in compile-time errors/warnings in case types are mismatched. Types do not always need to be declared, they can be inferred thanks to excellent https://github.com/alex-gutev/cl-form-types by Alex Gutev. Besides that it includes a collection of useful macros for more "typey" style of coding as well as several data structures I consider missing from the standard. The structures are templated -- which means there's a structure type generated for each contained element-type.
Before reading this, please go and check out https://github.com/digikar99/polymorphic-functions which this project is fully based on. It's great.
coalton you mean?
And, there won't be a way to properly understand what exactly PF (or CL) misses without immersing myself into a ML-style something, is there? As in, I get some parts of what you are saying; I myself had to (ab)use deftype and gensym intern for another library for providing (limited) parametric types; but I also fail to see something seriously wrong with it, given that it plays nicely with cl:declare, cl:typep and cl:subtypep for the primitive use case of single value type checking, declaration and with some additional things (compiler)macro based optimization.
Example: your equality polymorph here https://github.com/lisp-polymorph/polymorph.maths/blob/master/src/polymorph.maths.lisp
About static typing and generic functions, are there limitations to fast-generic-functions built over sealable-metaobjects too? I felt that reasonable, albeit it takes away the dynamic nature of the objects after sealing.
About static typing and generic functions, are there limitations to fast-generic-functions built over sealable-metaobjects too? I felt that reasonable, albeit it takes away the dynamic nature of the objects after sealing.
Well, CCL has a bug pertaining to signatures of funcallable-instances that may prevent things from working in certain cases.
Other times, the support is limited by the implementations supported by ctype and cl-form-types (and cl-environments). Although, if there is any good request, I could work on making a dynamic-only ANSI-CL compliant sub-system of PF.
What are your thoughts on the Lisp Interface Library? I recognize that it doesn't cover some of your use cases since LIL is designed in a dynamic manner and does not provide the sort of compile-time type shenanigans that coalton can. Just from the standpoint of providing parametric polymorphism though, dynamic or not, what do you think of it?