<p dir="ltr">Great points.</p>
<p dir="ltr">I often run into situations where sketching out non-terminating endpoints leads to a precise domain, but after peer review it becomes clear that a much simpler program would result from compromising with a less precise domain that eliminates these points altogether.</p>
<p dir="ltr">Eliminating branching on constructors in Haskell is a common aspect of this refinement, it's true.</p>
<p dir="ltr">Cheers,<br>
Darren</p>
<div class="gmail_quote">On Nov 1, 2015 03:18,  <<a href="mailto:joachifm@fastmail.fm">joachifm@fastmail.fm</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The ability to express non-termination is a feature, not a bug. If the<br>
program truly cannot produce a useful result for some input, it should<br>
crash, the earlier the better. Wrapping the return value ONLY to make a<br>
non-total program *appear* total is kind of ugly (and commits you to a<br>
potentially inappropriate/nonsensical model for the problem at hand). It<br>
is cleaner to either constrain the input to values you're prepared to<br>
deal with or crash when the implicit invariant is violated.<br>
<div class="elided-text">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></blockquote></div>