The Hacker News discussion about Coalton, a Lisp dialect with static typing, reveals several key themes regarding its purpose, advantages, and the complexities of integrating static typing with Lisp's macro system.
Coalton's Core Purpose: Bridging Lisp Dynamism with Static Typing Benefits
A central theme is Coalton's aim to bring the advantages of ML-style static typing, such as type safety and enhanced expressiveness, to the Common Lisp ecosystem. Users highlight that while Common Lisp is strongly typed, it lacks static type checking, leading to runtime errors rather than compile-time errors for type mismatches. Coalton seeks to move these checks to the compilation step.
- CraigJPerry notes that Coalton "is more about performance, removing the dynamicism - lisp (at least SBCL) is already type-safe." However, this is quickly clarified by others, suggesting that while SBCL might behave type-safe in some cases, it's not guaranteed at compile time.
- asplake explains that Coalton "brings ML-style polymorphism. Type safety is a given in that case, which may or may not be the case with CL."
- wild_egg states that CL "is strongly typed but not statically typed. The compiler generally doesn't complain ahead of time that your function is going to do math on a string... Typically a runtime condition will be signalled... Coalton moves that to the compilation step so you get an error back the instant you send the form to the REPL."
Enhanced Expressiveness and Composability Through Type Classes
The discussion frequently points to Coalton's ability to facilitate more expressive and composable abstractions, particularly through type classes, a feature common in languages like Haskell. This allows for ad hoc polymorphism, where function behavior can vary based on implemented type class instances.
- reikonomusha elaborates on this, stating that Coalton brings "abstractions that are only possible with static types, like ad hoc polymorphism via type classes. For example, type classes allow polymorphism on the return type rather than the argument types." An example provided is the
stringifyfunction with anInto :a String => :a -> :a -> Stringdeclaration. - tgbugs echoes this sentiment, recommending a video that "provides an excellent example of how the type system makes the language more expressive (by making it more composable)."
Performance Gains Through Static Analysis and Optimization
Another significant theme is the potential for performance improvements in Coalton due to static type information. This information allows the compiler to perform more aggressive optimizations that might not be safe or easily provable in a purely dynamic environment.
- reikonomusha details this, explaining that Coalton aims to make "high performance more accessible." He notes that while CL can achieve high performance, it often requires code that looks like "monomorphic imperative code." Coalton, with its optimizing compiler, can perform various optimizations that "Common Lisp often can't do because the language must respect the standard, which allows things to be redefined at run-time, for example."
- skulk provides concrete examples of how SBCL can optimize code when type declarations are present, such as using the
imulinstruction forunsigned-bytemultiplication instead of a generic*call that invokesSB-VM::GENERIC-*. This illustrates the underlying principle that static type knowledge aids performance.
The Interplay and Challenges of Lisp Macros and Static Typing
A major point of discussion revolves around the compatibility and challenges of integrating Lisp's powerful macro system with static typing. While it's generally agreed that macros themselves aren't inherently incompatible, special considerations arise when macros need to interact with or be aware of the type system.
- paddy_m questions the notion that macros are incompatible with static typing, suggesting that in a Lisp with optional static typing, macros could write types or leverage type information.
- reikonomusha clarifies that while Lisp macros work with Coalton, the difficulty arises when macros "must itself be (1) written in a statically typed manner... and (2) allowed to access the type environment of the surrounding context." He points to research languages like Hackett as attempting to solve the problem of "true typed and type-aware macros."
- kscarlet echoes this, stating that "Lisp macros do work, but only at the level of untyped S-expr. A Lisp macro can't know about types of the variables in the lexical environment, or expected type of its own context." They argue that while this might be sufficient for a "typescript-like" use case, achieving true type-aware macros that extend the type system is a significant challenge, potentially requiring extensible or bidirectional type systems.
- JonChesterfield probes this further by asking about "putting type annotations on the macro, and refusing to compile code where the arguments to the macro don't match the type."
- reikonomusha responds that this would involve "typing judgments... so that the type checker... can use those rules," essentially extending the type system, which is a "task fraught with peril."
User Experience and Example Breakages
The discussion also touches upon the practical user experience, with reports of broken examples on the Coalton website, which the project maintainers acknowledge and promise to fix.
- anentropic points out layout issues on non-maximised windows and reports that several examples on coalton.app, specifically the "Type Classes" and "JSON Parser" examples, have errors.
- agambrahma, a maintainer, acknowledges these issues and commits to fixing them.
Overall, the discussion paints a nuanced picture of Coalton as an ambitious project aiming to bring robust static typing to Lisp, with significant potential for improved expressiveness and performance. However, it also highlights the inherent complexities in marrying Lisp's dynamic, macro-heavy nature with the demands of a sound and extensible static type system.