Its not very smart to add static typing to Lisp, goes against the strengths of the language. At that point just program in another language, there’s a lot of benefit of static typing that IDEs can take advantage of but for anyone half decent at Lisp, they wouldn’t feel any need for static typing (outside of compiler optimisations, which is a different thing).

Now in terms of interesting things, check out European Lisp Symposium https://european-lisp-symposium.org/

The talks from this year were highly entertaining

The other really cool thing in CL IMO is Allegro Cache - in memory datastore that is a joy to use

> Its not very smart to add static typing to Lisp [...] (outside of compiler optimisations, which is a different thing)

i think this is precisely the point of coalton. cl allows quite handy compiler optimizations and having the option to drop into a native statically typed environment just gives more bang to your lisp ;)

coalton is not lispy, sure, but neither is the loop macro, yet it is probably the most powerful looping mechanism in any language :)

Those already exist and have been used by many.

Coalton is a set of macros to make it easier for to write with the safety rails of static typing.

Now if I write in Swift, for example, static typing is great, because the IDE can give a lot of hints during development. Non lisp languages have quite idiosyncratic syntaxes for various constructs, so static typing really does help a lot there. In large code bases in those languages it also helps a lot because they do not have the power of Lisp macros to reduce syntactical complexity via a Domain Specific Language.

Now with Common Lisp, with a powerful generic functions and object system, with runtime dispatch and introspection that far exceeds other languages, plus with the abstraction power of macros, trying to add static typing guard rails simply doesn’t make any sense. I rather program in TypeScript if I am so far removed from the core essence of CL development.

Each language has its strengths and the dynamic nature of CL is one of its biggest strengths (with the lack of a GUI and interop with other tools being its largest deficiencies today). Static typing in Lisp is like trying to fit a square plug in a round hole. If somebody wants so much guard rails, other languages are much more suitable because they have been designed (quite successfully if I may add) in that way.

TLDR; As per On Lisp by PG, lisp code should be built in layers over each other and hence static typing is unnecessary. Furthermore generic dispatch provides similar features to some extent (although i recommend combining with closer mop and catching edge cases etc)

> Static typing in Lisp is like trying to fit a square plug in a round hole. If somebody wants so much guard rails, other languages are much more suitable because they have been designed (quite successfully if I may add) in that way.

i belive the author of the coalton package is not very concerned with IDEs or putting up safety nets for developers. i think he uses coalton for making optimizing compilers. think of it as cl+ml not as cl+ts

EDIT: typos

> lisp code should be built in layers over each other and hence static typing is unnecessary

It could help for refactoring though.

> coalton is not lispy, sure, but neither is the loop macro, yet it is probably the most powerful looping mechanism in any language :)

I would argue that iterate is more powerful as well as being more lispy in the sense that it's extensible and macro-programmable.

https://iterate.common-lisp.dev/

I like the lispiness and features of ITERATE but it breaks source location for debugging errors in SBCL with SLIME. Instead the ITER form is indicated, which dampens my enthusiasm for it somewhat.

  (defpackage :test
    (:use :cl :iterate))

  (in-package :test)

  (defun test-iter ()
    (declare (optimize (debug 3) (safety 3) (speed 0)))
    (iter:iter   ;;; <-- highlights whole ITER form
      (sleep 2)
      (error "test")))

  (defun test-loop ()
    (declare (optimize (debug 3) (safety 3) (speed 0)))
    (loop
      :do (sleep 2)
      :do (error "test")))   ;;; <-- highlights ERROR form

Iterate also breaks the count function. Or did the last time I tried to use it.

What do you mean?

Just checked and this is still a problem. Try this code with Iterate:

  (let ((list '(1 2 3 4 1 2 3 4))) ;; or whatever other sequence
    (iter (for i from 1 to 10)
          (sum (count i list))))

It will error out on you. The same works fine with loop:

  (let ((list '(1 2 3 4 1 2 3 4)))
    (loop for i from 1 to 10
          sum (count i list))) ;; => 8

Now, that's a bit contrived as an example, but an iteration library should not break a standard library function call.

https://gitlab.common-lisp.net/iterate/iterate/-/issues/12 - Apparently it's known and they intend to remove it in 2.0, which isn't out yet.

good to know, thanks

You bring a good point about the loop macro (which I do like too). Maybe you are right. My personal feeling is trying to do static typing will lead to less elegant code (I say less elegant, because any code that works and is fast enough is good enough - style doesn’t matter that much, esp if readability is somewhat maintained) and has more far reaching implications on a code base than the loop macro which can be isolated to a specific section.

But I get your point too, for those who crave static typing, then at least there’s something for them to try.

Java's type system is just powerful enough that sometimes you can approach a problem in a way that resembles a different paradigm than normal, i.e. you solve it with the type system itself much more so than what's expressed by particular procedural or object-oriented or declarative code along the way. Supposedly Haskell encourages this approach as its primary one (and the approach sometimes gets called the "functional programming paradigm" but that I think is a misnomer as FP is primarily about immutability and higher order functions, not static types), to the same extent Java otherwise encourages a Java-style-OOP approach to most things, but I'm too unfamiliar with Haskell to make this claim with high confidence.

Still, different paradigms are useful, and one of the best things about Lisp is you aren't forced into one, and there's no threat of one being taken away from you. Coalton to me seems nice for people who like what it provides, it's nice that it exists, even though I don't see myself using it anytime soon since I don't personally enjoy working in that paradigm. There are two other non-type-proofs-paradigm benefits of static typing, but I don't really miss them in CL. The first is related to automatic refactoring tools, but Lisp has features to ease refactoring to compensate, and text-search methods for renaming aren't that bad (and even in Java necessary if you want to make sure you haven't missed reflection calls, though even then you can miss some) and anyway one can read the second edition of the Refactoring book that uses JavaScript if one needs convincing that refactoring can be done just fine even in a lower quality dynamic lang. The second is related to trivial conveniences like compile-time typo protection on symbol names, interface mismatches (like swapped function call argument order -- but failing to that indicates I have an unintuitive interface, and CL has many tools to help me make it better the simplest being keyword arguments), and faster assembly code. But SBCL's handling of the standard CL type system is good enough to get all of those things to a pleasing degree.

I'd add one other feature of Haskell- and ML-style type systems that I like: they provide clear, succinct, convenient ways to precisely describe data structures.

Common Lisp is far and away my favorite surviving programming language, but I like Haskell and ML fairly well. I mean, when I've been paid to work in them, I definitely missed working in Lisp, but still, working in Haskell and ML is not torture. I liked it quite a bit better than working in some other languages.

One of the things I liked was the ability to succinctly express in some detail exactly what I intend some data structure to be.

I've even used Haskell as a data-description language to work out some data structure that I then implemented in Lisp.

I keep intending to do something with Coalton for this reason alone.

Great comment, agree a lot with this

Thanks for sharing, nice to see SisCog still at it.

Did they record the talks this year?

I think so, try asking on reddit or IRC if you still can’t find them via some google fu

Racket. With typed racket.