Hacker News Reader

Comment by reikonomusha | Hacker News Reader

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/

View on HN

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.

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...

Wouldn't that be something that the tooling could deal with easily? I don't know if there is anything like that yet, but the last time I took a quick look at Coalton it seemed like some basic SLIME and ASDF etc support with its own filetype and Emacs mode to go with it could be potentially useful and fun little project.

Lem's Coalton mode looks good: https://lem-project.github.io/modes/coalton-lang/

Nice, pretty much what I had in mind. I think there could be some interesting potential there tooling wise. Combining a highly dynamic interactive environment with a good statically typed language sounds fascinating to me and it's something that at least to my knowledge has never been seriously tried. Only Strongtalk comes to mind but I have no idea how it was like in practice, and I assume the type system was something closer to Java.

Reply on news.ycombinator.com