[ivanb]

It is probably the best Common Lisp compiler when it comes to type checking. However, it leaves a lot to be desired. For example, it cannot specialize an element type for lists. With lists being the go-to structure, if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python.

The ability to specialize list parameter types would greatly improve type checking. It would also help the compiler to optimize lists into unboxed arrays.

Please don't tell me that static type checking doesn't lend itself to CL. The ship has sailed. It does work with SBCL rather well, but it can be better.

Some may blame the Common Lisp standard. It indeed doesn't specify a way for list specialization, but the syntax is extensible, so why not make it as a vendor extension, with a CDR? AFAIK CDR was supposed to be to Common Lisp what PEP is to Python.

I would use vectors and arrays, but in CL ergonomics is strongly on the side of lists. For short structures vectors and arrays don't make sense.

I think it is also a time to outgrow the standard and be more brave with extensions. A lot has changed since the standard. It is still very capable, but as powerful as CL is, some things just cannot be practically implemented in the language and have to be a part of the runtime. Yes, I'm talking about async stuff.

So I got the idea to see how difficult it would be to bolt on async runtime to SBCL. To my surprise the project is hosted on awfully slow SourceForge and project discussions are still happening on mailing lists. Sorry, but I am too corrupted by GitHub's convenience.

[a-french-anon]

>For example, it cannot specialize an element type for lists.

Yes, but that would be a CL violation (or an extension to provide via something else than DEFTYPE), since DEFTYPE's body can't be infinitely recursive; cf https://www.lispworks.com/documentation/HyperSpec/Body/m_def...

>if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python.

Indeed, but 1) it is used by the compiler itself while cpython currently ignores annotations and 2) runtime and buildtime typing use the same semantics and syntax, so you don't need band-aids like https://github.com/agronholm/typeguard

But yeah, CL's type system is lacking in many places. In order of practical advantages and difficulty to add (maybe): recursive DEFTYPE, typed HASH-TABLEs (I mean the keys and values), static typing of CLOS slots (invasive, like https://github.com/marcoheisig/fast-generic-functions), ..., parametric typing beyond ARRAYs.

[ivanb]

>Yes, but that would be a CL violation

Let's be brave and deviate from the standard, preferably in a backward-compatible way, to provide the best achievable DX.

The CL committee, however smart it was, could not think through all the nooks and crannies of the system. Let's continue where they left off and progress.

[reikonomusha]

Coalton [1] adds Haskell-style types (so typed lists, type classes, parametric polymorphism, ...) to Common Lisp, and compiles to especially efficient code in SBCL.

[1] https://coalton-lang.github.io/

[tkrn]

Describing Coalton as a CL add-on or even as a DSL has always seemed wrong to me. It's of course very tightly integrated with the Common Lisp runtime but it's also very different as an actual language. And I mean that in a positive way as being different from CL is both an achievement but also a requirement for doing what it does.

I just found it funny how Clojure's lack of cons pairs is enough to cause religious debates about its Lisp nature while (ISTR) adding symbols to Coalton basically requires foreign calls to the host system, but it still counts as a CL-with-types.

[ivanb]

Coalton is nice but it requires a wrapper around every form you feed a REPL or around the whole file.

If on the other hand SBCL had a more powerful type system or extension points for a pluggable type system...

[cess11]

How would your async stuff differ from the threading interface in SBCL and e.g. lparallel and bordeaux-threads?

[ivanb]

The same way threads are different from goroutines, green threads, JS event loop etc.