This is why it's important to always look at the issues on a repo instead of just believing what's in the README. It fails to detect type errors in some of the most basic situations
Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton developers have to decide what they want to do about it. Haskell chose pervasive functional purity and monads (but still gives you many type-unsafe escape hatches). OCaml chose weak polymorphism. [3]
Being a sensitive design choice, Coalton has not committed to a strategy for dealing with this, so as it stands, it is possible to use a combination of impure features to produce a type error. However, this does not block productive development. One can:
- Avoid mutation altogether and rely on an otherwise sound type system. Use purely functional data structures built in to the language, or write your own.
- Use mutation in monomorphic scenarios where there will not be any issue.
- Mutate outside of Coalton (i.e., in Common Lisp).
- Be very careful, know that "Here Be Dragons", and carefully use mutation in a polymorphic context, understanding that one runs the risk of a type error.
Until Coalton reaches "1.0" and a language design choice is made around mutation and the type system, one of these strategies must be used. And they have been used, successfully, because idiomatic Coalton code isn't typically mutating polymorphic vectors left-and-right anyway.
With all that said, I do agree with examining a language or tool for caveats, known bugs, and limitations. I don't know how you'd make engineering trade-offs otherwise.
[1] "Using Coalton to Implement a Quantum Compiler" https://coalton-lang.github.io/20220906-quantum-compiler/
[2] "A Language-Oriented Approach to Exchange-Only Silicon Dot Qubit Software" https://youtu.be/F8TezGqCvE8
This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party solution available here," it's like the responder has missed the whole point.
Most programmers seem to care what the library ecosystem has to offer, though, so long as said libraries are actually working and useful. Is Coalton such? It's a technology that has been in development for around 5 years, that is presently used for commercial purposes, and that offers an approach to static typing a la Haskell's type system within Common Lisp projects. It's not a slapdash weekend project that purports to do something, only to find it really only does 5% of what was advertised. All things considered, it seems reasonable to suggest it as an option for static typing.
Production-readiness is a gradient. (Or, less usefully, it's a binary quality determined by the question, "Is it used in production at a company?") I wouldn't personally use Coalton to build real-time rocket control software for many reasons, the most important of which is that it's not billed as a "1.0" product. But I also wouldn't dismiss it because it has a bug tracker with an exposition on an intrinsic limitation of Hindley-Milner type inference. Coalton is a tool built in Common Lisp that is used in production, today, now, as documented by those links in my GP comment. You can even be paid real money to develop Coalton and/or software in Coalton.
Look, I get that people are tired of this peculiar rhetoric, the
> Lisp has macros therefore it's always one step away from implementing any popular language feature.
kind. For a variety of reasons, it's usually not true in a practical sense, and ultimately leaves the would-be user holding the bag.
I suggest, however, that Coalton really isn't a smokescreen that just exists to duly check off a "Has Static Types?" feature checkbox for Common Lisp.
this makes it sound like the developers are lying whereas the issue was raised by one of the core developers
> fails to detect type errors in some of the most basic situations
i dont think this is a basic situation. i wouldnt do mutation at coalton level, instead at lisp level