5 ms·

Yep. It's easier to implement and makes more sense in a lazy language than what you're describing though. I don't use it in my work but I do use a related techn

• coolsunglasses 10y ago
  To elaborate a little on this: In a strict language, a type error would mean the bricked off expression that doesn't type-check would spread like an infection to any expression that incorporated it. In Haskell, I can dance around sub-expressions that don't type-check at runtime and evaluate things optionally. The technique doesn't work in practice otherwise.
  • tome 10y ago
    > The technique doesn't work in practice otherwise. I don't see why. Functions in a strict language are evaluated lazily. Any type error within a function wouldn't spread beyond that function.
    • coolsunglasses 10y ago
      Values still wouldn't work. You'd have to change their types to `() -> whatever` and that means a lot of churn. Even strict-by-default languages that let you easily make values explicitly lazy would mean type level churn, if not term level. The value part is important because it means you can't really talk about partially implemented hypothetical results where you know how to handle one branch of a function, but not another. This is a super common divide-and-conquer technique in Haskell. Could possibly half-ass it if you have some kind of panic functionality, but it'll fail unconditionally in a strict language when the result of the function is forced. In Haskell, if you don't use the bottom, it doesn't blow up.