4 ms·

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

110 points by reikonomusha 3y ago

brabel 3y ago
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/ https://coalton-lang.github.io/20211010-introducing-coalton/
- bmitc 3y ago
  How does Coalton compare to Shen?
  - reikonomusha 3y ago
    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.
- reikonomusha 3y ago
  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))
  - coryrc 3y ago
    Could replace `eval` in a namespace?
    - reikonomusha 3y ago
      The ultimate plan would be to just have a special Coalton REPL, that would allow more features and better diagnostics.
- Blackthorn 3y ago
  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.
dunefox 3y ago
Coalton seems great, I love the idea. This issue seems problematic, though: https://github.com/coalton-lang/coalton/issues/84 https://github.com/coalton-lang/coalton/issues/84
- wk_end 3y ago
  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.
  - kazinator 3y ago
    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.
- deleted 3y ago
  [deleted]
perihelions 3y ago
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).
- deleted 3y ago
  [deleted]
- User23 3y ago
  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.
  - deleted 3y ago
    [deleted]
reikonomusha 3y ago
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.
koito17 3y ago
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).
- reikonomusha 3y ago
  Coalton's type system is roughly the same as Haskell's or OCaml. That includes full type inference, type variables, type classes, etc.
  - koito17 3y ago
    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 https://www.cis.upenn.edu/~bcpierce/papers/lti.pdf [2] https://www2.ccs.neu.edu/racket/pubs/esop09-sthf.pdf https://www2.ccs.neu.edu/racket/pubs/esop09-sthf.pdf
cat_plus_plus 3y ago
[flagged]
- dunefox 3y ago
  Do you know what a lisp is?
Terr_ 3y ago
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.

110 points by reikonomusha 3y ago

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/ https://coalton-lang.github.io/20211010-introducing-coalton/

bmitc 3y ago
How does Coalton compare to Shen?
- reikonomusha 3y ago
  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.
reikonomusha 3y ago
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))
- coryrc 3y ago
  Could replace `eval` in a namespace?
  - reikonomusha 3y ago
    The ultimate plan would be to just have a special Coalton REPL, that would allow more features and better diagnostics.
Blackthorn 3y ago
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.

dunefox 3y ago

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

wk_end 3y ago
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.
- kazinator 3y ago
  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.
deleted 3y ago
[deleted]

perihelions 3y ago

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

deleted 3y ago
[deleted]
User23 3y ago
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.
- deleted 3y ago
  [deleted]

reikonomusha 3y ago

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.

koito17 3y ago

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

reikonomusha 3y ago
Coalton's type system is roughly the same as Haskell's or OCaml. That includes full type inference, type variables, type classes, etc.
- koito17 3y ago
  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 https://www.cis.upenn.edu/~bcpierce/papers/lti.pdf [2] https://www2.ccs.neu.edu/racket/pubs/esop09-sthf.pdf https://www2.ccs.neu.edu/racket/pubs/esop09-sthf.pdf

cat_plus_plus 3y ago

[flagged]

dunefox 3y ago
Do you know what a lisp is?

Terr_ 3y ago

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.