Coalton Blog

> But I don't think of these as programming language

I don’t want to get too caught up in what counts as a programming language, but you can absolutely write programs in a language like Lean, e.g. computing factorial 10. The fact that you can also write proofs doesn’t negate a system's status as a programming language. It’s worth noting that the official Lean documentation reflects this dual use: https://lean-lang.org/documentation/.

So there’s no conflation... just a system that supports both orientations, depending on how you use it.

> SQL [...] ought not to be conflated

I agree that SQL isn’t a general-purpose programming language, but you said something to the effect of "I don't understand what meaning a program has beyond what it does", and if you know about SQL, then I think you do understand that a program can have "computational meaning" that is separate from its meaning when you run it through an interpreter or processor.

> You want Coalton :-)

Thanks for the pointer. I am going to read https://coalton-lang.github.io/20211212-typeclasses/ , hoping to eventually achieve clarity on the relation between multiple dispatch and type classes..

That said, my interest in generic programming pushes pretty hard toward dependent types. I’m increasingly convinced that many patterns in dynamic programs, especially those involving runtime dispatch, require dependent types in order to be typed. Coalton might help me understand better the relation also between interactivity…

I can't speak from a professional level about this, but I'll tell you why I started using Common Lisp for my personal development.

One day I was thinking it would be awesome if someone created a really powerful language with great facilities for abstraction: first class functions, objects, meta objects, etc. It should use dynamic typing during development with an excellent REPL and a built in debugger available everywhere, but it should have the ability to add type declarations when the code got more settled.

Even better, this language should include ways of hinting to the compiler how to make a chunk of code faster, and if that wasn't enough, you should be able to replace chunks of code seamlessly with highly optimized C code.

I thought about how to implement a language like this for a while, but when I looked into it I discovered Common Lisp does most of this already. It's static typing isn't perfect, though now there is https://coalton-lang.github.io/ if that's your thing.

So that did it for me, but really this is only part of what you can do with Common Lisp. I think it still has a niche in places where the "right thing" isn't know yet.

For example, I read a Reddit post saying that Common Lisp would be a poor choice now for a web startup, and that Paul Graham overstates Common Lisp's case as the reason for Viaweb's success. This is probably true in 2022, but I think it's instructive to look at why Paul claimed Lisp was so helpful back in 1996. There was no…

That one is quite interesting indeed.

And they use it for quantum computing research:

"One of the state-of-the-art optimizing quantum compilers is an open-source program called QUILC with a companion quantum computer simulator called the Quantum Virtual Machine. Both of these programs are written in 100% Common Lisp, and contain a total of around 50,000 lines of sophisticated, mathematical, data structure–heavy code. And that excludes the plethora of first-party dependencies.

Common Lisp is a fantastic language for developing these programs; it’s fast, stable, extremely flexible, and the developer experience is unmatched. But, both new and seasoned developers sometimes get tripped up and tangled in the web of complex data structures, and inadvertently introduce type errors that the relatively comprehensive test suite doesn’t catch. In addition, such developers heavily rely on documentation strings (“docstrings”) in order to discover what the probable inputs and outputs of the functions are, and those docstrings sometimes go stale.

Coalton’s aim is to allow us to reap the benefits of Common Lisp, and not have to rewrite 50,000 lines of tricky code in order to realize some of the benefits offered by statically typed functional programming languages."
https://coalton-lang.github.io/20211010-introducing-coalton/

Type declarations in ANSI CL are promises you make to the compiler in order to allow it to generate faster code. The compiler can also use this information to generate compile-time warnings and errors, but it is not required to. This makes CL's native compile-time type system good for making your code fast, not so much for making it reliable. But it's straightforward to layer a proper modern type checker on top of CL, and in fact this has been done. It's called Coalton:

https://coalton-lang.github.io/

IMHO this is the Right Answer: types when you want/need them, dynamism when you don't. It seems like a no-brainer to me. I've never understood why so many people think it has to be one or the other. It seems to me like arguing over whether the window on the bike shed should be on the left or the right. If there is disagreement over this, just put in two windows!

CL also has pretty much arbitrarily extensible syntax:

- https://sr.ht/~dieggsy/whisper/

- https://dieggsy.com/json-literals.html

And could also be used to build languages, supporting more modern programming paradigms (though yes, I believe Racket does make this easier):

- https://coalton-lang.github.io/

I also might have written the Common Lisp example using reduce as well, which is in the standard library, but that's preference. Nice to have the option though:

(defun calculate (instructions)
(reduce
(lambda (result op-value)
(destructuring-bind (operation value) op-value
(case operation
(:add (+ result value))
(:subtract (- result value))
(:multiply (* result value)))))
instructions
:initial-value 0))

(calculate '((:add 5) (:multiply 3) (:subtract 4))) ;; => 11

There is an explanation in the blog: https://coalton-lang.github.io/20260424-mine/

> However, the above is a tall order for someone just wanting to dip their toes in, to see if they have any interest in Coalton or Common Lisp. A couple hours on the weekend is easily sunk into getting configurations right, and the right subsystems installed, and the right paths setup, just so the first line of code can be executed.

> mine is not Emacs. It aims to eliminate all of that, and be a Coalton/Lisp-first development environment, whose only job is to be a Coalton/Lisp-first development environment. But more than that, it needs to be accessible. A non-programmer should find it easy to download, install, and run mine with nothing more than a download link.