[HN Gopher] Introducing Coalton to lispers without a background ...
___________________________________________________________________
Introducing Coalton to lispers without a background in ML-like
languages
Author : reikonomusha
Score : 71 points
Date : 2023-08-26 05:53 UTC (17 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| brabel wrote:
| 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/
| reikonomusha wrote:
| 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))
| bmitc wrote:
| How does Coalton compare to Shen?
| reikonomusha wrote:
| 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 wrote:
| 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.
| perihelions wrote:
| 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).
| User23 wrote:
| 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]
| [deleted]
| dunefox wrote:
| Coalton seems great, I love the idea. This issue seems
| problematic, though: https://github.com/coalton-
| lang/coalton/issues/84
| [deleted]
| wk_end wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-26 23:00 UTC)