News for hackers. Stuff that matters.
Re:Using SBCL Common Lisp as a Dynamic Library by bitwize on Saturday April 16, 2022 @06:51PM (#31056809)
Type systems at least as rich as Hindley-Milner are pretty much table stakes in 2022. Common Lisp's type system is not as rich as Hindley-Milner. I believe it doesn't even support user-defined parametric types (so it's kind of like pre-generics Go in that regard). It lets you type function args, but it doesn't incorporate the args' types into the function type.

So no, Common Lisp's type system, even with static type checking enabled, is not adequate for software engineering in the present day. Coalton, however, solves many of these problems.

Re:Using SBCL Common Lisp as a Dynamic Library by KerrAvon on Saturday April 16, 2022 @06:59PM (#31056870)
What languages in common use in 2022 support a Hindley-Milner type system? This sounds a bit like pointless academic gatekeeping…
Re:Using SBCL Common Lisp as a Dynamic Library by bitwize on Saturday April 16, 2022 @07:08PM (#31056905)
Basically, any statically typed language with parametric polymorphism, so Ada, C++, Java, C#, Rust, TypeScript, Python with static-typing support, post-Delphi Pascal, and recently Go all qualify.
Re:Using SBCL Common Lisp as a Dynamic Library by reikonomusha on Saturday April 16, 2022 @07:23PM (#31056979)
Parametric polymorphism != Hindley-Milner, not even basically. H-M is a construction for describing and ascertaining types of terms in a lambda calculus. Many of those languages don't even typically idiomatically achieve polymorphism through generic types (though of course it's possible), but instead from subtype and ad hoc polymorphism. I don't think it's accurate to imply their designs orbit H-M.

I don't want to belabor on technicalities. Your original point was about "table stakes" for type systems in order to be relevant for modern-day software engineering. While I agree a language that attempts to incorporate fashionable computational constructs (like variable binding and lambda terms) ought to derive its type system from something H-M-esque—if only because it's so well understood—it's certainly not a requirement for the language to be taken seriously, and it's certainly not without significant peril in the presence of mutation constructions. I honestly think C, vanilla Common Lisp, and pre-generic Go are sufficiently disparate examples of that.

Re:Using SBCL Common Lisp as a Dynamic Library by dbmacqueen on Sunday April 17, 2022 @04:32PM (#31064196)
Type inference is hinted at in a 1934 paper by Haskell Curry on "functionality" (i.e. types) for combinatory logic. Max Newman (Turning mentor and leader of the Colossus project at Bletchley Park) published a paper in 1943 giving the first algorithm for type inference for the lambda calculus that I know of.
Re:Using SBCL Common Lisp as a Dynamic Library by User23 on Saturday April 16, 2022 @09:28PM (#31057630)
Comparing Go generics to those other languages is putting on some very rosy colored glasses. The primary design goal of the current generics implementation appears to have been discouraging their use. I hope they'll iterate on it, but at this point they're basically painful and annoying at best.
Re:Using SBCL Common Lisp as a Dynamic Library by BigJono on Saturday April 16, 2022 @10:43PM (#31057991)
Table stakes for what? Fucking around with types for 6 months while someone builds a competitor in a weekend?