Introducing Coalton to lispers without a background in ML-like languages | Hacker News Reader

Introducing Coalton to lispers without a background in ML-like languages

gist.github.com

110 pointsreikonomusha18 comments

Coalton has a lot of promise and looks really nice.

For the uninitiated, it's a functional language of the Lisp family, with a type system somewhat close to Haskell's (or a ML descendant) that lives *embedded* in Common Lisp.

The problem to me seems to be just how inconvenient it is to use, exactly because it's embedded in another language!

Being able to use SLIME is of course, very nice, but having to wrap every expression you enter in `(coalton ...)` is a pain... I know they're working to make that more convenient, can't wait to try it again once that's done!

EDIT: intro to the language for those interested: https://coalton-lang.github.io/20211010-introducing-coalton/

How does Coalton compare to Shen?

Coalton uses a more familiar type system (like Haskell's or Rust's), and doesn't attempt to be an independent language from Common Lisp.

If it's too painful, a one-line read macro on % (or so) can make it simpler to type.

    (set-macro-character #\% (lambda (s c) `(coalton ,(read s))))

Then one can type

    %(f (g x))

Could replace `eval` in a namespace?

The ultimate plan would be to just have a special Coalton REPL, that would allow more features and better diagnostics.

I wonder if the Common Lisp implementations can get together and create one of those CDRs about always-on macros (and how to order them etc etc). Not sure how else one would solve this issue, but I'm surprised that isn't available.

Coalton is used in production at HRL Laboratories for quantum computing software. The language still needs work (especially DX) to reach a comfortable 1.0, but it's powerful and correct enough to displace otherwise difficult-to-write Common Lisp code.

How does Coalton's type system compare to that of Typed Clojure? Recently, Typed Clojure received huge improvements to local type inference such that

  (let [f (comp (fn [y] y)
                (fn [x] x))]
    (f 1))

can be inferred to return a value with type (Val 1) through serious amounts of symbolic execution.

Does Coalton have similar capabilities? I would love to try out some kind of "typed Common Lisp", especially since I prefer Common Lisp over Clojure any day, but recent advancements in Typed Clojure have been raising my eyebrows, as they it can finally do things that were once considered infeasible (declaring types for higher-order functions and heterogeneous collections in a dynamic language).

Coalton's type system is roughly the same as Haskell's or OCaml. That includes full type inference, type variables, type classes, etc.

Ah, so it is closer to a Hindley–Milner type system than something like Typed Racket's type system. Typed Clojure is largely based off of the latter and takes inspiration from some papers on local type inference[1] and [2] to handle multi-arity functions. I should look more into Coalton. Thanks for responding.

[1] https://www.cis.upenn.edu/~bcpierce/papers/lti.pdf

[2] https://www2.ccs.neu.edu/racket/pubs/esop09-sthf.pdf

Coalton seems great, I love the idea. This issue seems problematic, though: https://github.com/coalton-lang/coalton/issues/84

It's a known issue with HM type systems in the presence of mutation with known remedies (linked in that ticket), so I don't think it's insurmountable. It's maybe a little concerning that it hasn't been addressed in ~two years, but I understand that the Coalton team's is small and have to prioritize; while soundness is a virtue, in my experience working with languages like this, you run into the value restriction quite rarely in practice.

It might be possible that they logged the bug just to say, "Yes, we know this academic problem exists in Coalton" and don't actually care about it.

SBCL is an inspiring and very interesting compiler, and it bolts a static-typing system onto Common Lisp that often lets it do pretty decent native-code compilation. In my ignorant opinion offered up in the spirit of Cunningham's Law, the parts it falls short on don't seem to be related to inadequate static typing. Rather, I feel major pain points are things like (0) the backend codegen seriously sucks, compared to the million-man-hour compilers like that languages like C have. Auto-vectorization is the most obvious of a long list of shortcomings. (1) The core Common Lisp language lacks ways to express basic and critical zero-overhead abstractions, like unboxed arrays of structs. (The zero-overhead subset of SBCL/CL is less expressive than C! Arguably!) (2) Though Lisp macros are great zero-overhead abstractions, Lisp's functional programming abstractions are often pretty expensive, so "lean" Lisp ends up looking disturbingly like plain, procedural C (and an inexpressive subset of it at that). (Or is this some unavoidable consequence of the excessive dynamicism of CL, that a very expressively typed Lisp could potentially solve? I don't know).

I don’t see why a simple array of structs couldn’t have each element be the struct itself, but I don’t know if any implementation takes advantage.

For a moment I parsed that garden-path sentence as introducing a ML system to recognize spoken language from people who lisp badly.

On reflection, I guess there might be a niche for such a product, but it seems like a dang small one.

Reply on news.ycombinator.com