2 ms·
Don't Rust and Haskell "solve" this by just copping to an NP-hard compilation task and trying to do it anyway?
by morelisp 4y ago
Don't Rust and Haskell "solve" this by just copping to an NP-hard compilation task and trying to do it anyway?
- pas 4y agoThe usual way is to add a lot of special case heuristic for it, hope those work, and if they don't then bail out. (Report an error to the developer, so then they can nudge the types a bit an hope to find a setup where one of the heuristics work.) And it's fine if the error messages are helpful, but this added implicit complexity to the language rightly gives folks the heebie-jeebies (se the recent comments for Rust's GAT patches)
- orlp 4y agoAs an N=1 sample point, I've programmed in Rust for years now, extensively using generics, and have not once ran into this issue. NP-hardness only shows the worst case is really difficult. It does not mean that an approach is not useful. For example, Rust's exhaustive pattern matching is also technically NP-hard: https://niedzejkob.p4.team/rust-np/ https://niedzejkob.p4.team/rust-np/
- morelisp 4y agoYeah, I don't mean to criticize the approach taken by other languages at all. Programmers want powerful type systems and fast compilation times and good error messages, and unfortunately this is one of the cases where things are really fundamentally, mathematically provably, at odds with each other in PL ergonomics. It's a wicked problem, not one you can "get it right". But these "Go's ignoring decades of PL research!" comments are, at best, tiresome even when somewhat true. In this case it's the outright opposite.