<div class="gmail_quote">Hello,<br>I was advised respectfully to post my query here.<br>Please, read the whole letter before you do anything, because I tried to construct the problem step by step.<br>Also keep in mind, that the problem I query here is more general, and similar cases occur elsewhere, not just in this particular example I present below.</div>
<div class="gmail_quote"><div class="im"><br><b>Intro story</b> ( Skip if you are in a hurry )<br>I'm participating in several open-source server development projects, most of them are written in C, and some of them have C++ code hidden here and there.<br>
These programs, are developed by many, and by many ways, and so, more often than not it is very hard to determine the 'real cause of bugs'.<br></div>This almost always leads to 'bugfixes' which 'treat the crash'. Sometimes they are a few lines of extra checks, like IFs.</div>
<div><div></div><div class="h5"><div class="gmail_quote">Sometimes they are complex, and even surprisingly clever hacks.<br>Thus understanding the 'code' of them is challenging, but the end result is a pile of ... hacks fixing bugs fixing hacks fixing bug, which also were put there to fix yet another bugs.<br>
+<br>When I started to learn functional programming, I was told, that the correctness of a functional program can be proved a lot more easily, in fact in a straight mathematical way.</div></div></div><div class="gmail_quote">
+<br><b>My concern</b><div><div><div></div><div class="h5"><div>is about predictable failure of sw written in Haskell.<br>To illustrate it let's see a Haskell pattern matching example:<br><br>Let's say I have defined some states my object could be in, and I did in a switch in some C-like language:<br>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
switch ( x )</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
{</blockquote></div><blockquote>Case 0:</blockquote><div><blockquote> "Unchecked"</blockquote><blockquote>Case 1: </blockquote><blockquote> "Checked"</blockquote></div><blockquote>Case 2:</blockquote>
<div><blockquote> "Unknown"</blockquote><blockquote>}</blockquote><br>And in Haskell pattern matching:<br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
switch 1 = "Unchecked"</blockquote></div></div></div><div><div><div></div><div class="h5"><blockquote>switch 2 = "Checked"</blockquote><div><blockquote>switch 3 = "Unknown"</blockquote><br>
Let's say, these are clearly defined states of some objects.<br>Then let's say something unexpected happens: x gets something else than 0 1 2.<br>Now we have a problem,<span style="text-decoration: underline; "> which is most generally fixed in these ways</span>:<br>
C-like:<br><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
switch ( x )</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
{</blockquote></div><blockquote>Case 0:</blockquote><div><blockquote> "Unchecked"</blockquote><blockquote>Case 1: </blockquote><blockquote> "Checked"</blockquote></div><blockquote>Case 2:</blockquote>
<blockquote> "Unknown"</blockquote><blockquote>Default:</blockquote><blockquote> "Nothing"</blockquote><blockquote>}</blockquote><br>Haskell like:<br><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
switch 1 = "Unchecked"</blockquote><div><blockquote>switch 2 = "Checked"</blockquote><blockquote>switch 3 = "Unknown"</blockquote></div><blockquote>switch x = "Nothing"</blockquote>
These general ways really avoid this particular crash, but <span style="text-decoration: underline; ">does something real bad to the code in my opinion.</span></div><div><span style="text-decoration: underline; "><br></span></div>
</div></div><div>Below are some cases x can go wrong:</div><div class="im"><div><i>1. The bad data we got as 'x', could have came from an <span style="text-decoration: underline; ">another part of our very program</span>, which is the REAL CAUSE of the crash, but we successfully hide it.</i></div>
</div><div><i><div class="im">Which makes it harder to fix later, and thus eventually means the death of the software product. Eventually someone has to rewrite it.<br>Which is economically bad for the company, since rewriting implies increased costs.<br>
<br>2. The bad data we got as 'x', could also could have come form a real word<span style="text-decoration: underline; "> object, we have underestimated, or which changed</span> in the meantime.<br><br>3. This 'x' could have been corrupted over a network, or by 'mingling' or by other faulty software or something.<br>
<br></div><span style="font-style: normal; "><div class="im">Point 1:<br>If we allow ourself such general bugfixes, we eventually kill the ability of the project to 'evolve'.<br><br>Point 2:<br></div>Programmers eventually take up such 'arguably bad' habits, thus making harder to find such bugs.<div class="im">
<br>Thus it would be wiser to tell my people to never write Default cases, and such general pattern matching cases.<br><br></div></span></i></div><div class="im"><div>Which leads to the very reason I wrote to you:<br><br>
</div></div><div><div class="im">I want to propose this for Haskell prime:<br><br>I would like to have a way for Haskell, not to crash, when my coders write pattern matching without the above mentioned general case.<br>Like having the compiler auto-include those general cases for us,<br>
but when those cases got hit, then<b> instead of crashing</b>, it <b>should </b><b>report some error</b> on <i>stdout </i>or <i>stderr</i>.<br></div>(It would be even nicer if it cold have been traced.)<div class="im"><br>
<br>This is very much like warning suppression, just that it's crash suppression, with the need of a report message of course.</div></div><div class="im"><div><span style="text-decoration: underline; "><br></span></div>
<div><b>I would like to hear your opinion on this.</b><br><br>I also think, that there are many similar cases in haskell, where not crashing, just error reporting would be way more beneficial.<br>In my case for server software, where network corrupted data,</div>
<div>( and data which has been 'tampered with' by some 'good guy' who think he's robin hood if he can 'hack' the server )<br>is an every day reality.</div></div><div><div class="im"><br><br>Thanks for your time reading my 'storm'.<br>
<br></div>Greets,</div><div><br>Andrew<br></div></div></div></div><br>