<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=RU link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-GB>By the way, there are a lot of articles why checked exceptions are bad design (more problems than benefit).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>More interesting for me is this snippet:</span></p><p class=MsoNoSpacing style='margin-left:36.0pt'><span style='font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNoSpacing style='margin-left:36.0pt'><span style='font-family:Consolas'>case (action :: Either err a) of<o:p></o:p></span></p><p class=MsoNoSpacing style='margin-left:36.0pt'><span style='font-family:Consolas'> Right result -> ...<o:p></o:p></span></p><p class=MsoNoSpacing style='margin-left:36.0pt'><span style='font-family:Consolas'> Left err -> deal_with err<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Somebody says me that to use Bool in such way is “not safe” because no way to know what does “True” returning from “action” mean. Success or failure? But with some ADT (Success|Failure) code is more Haskellish and safe.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>But is it true? We are talking about semantics, not type-safety because type-checker passes both cases (positive branch under False/Failure, negative branch under True/Success). But the same with Right/Left: nothing says you to use Right for positive and Left for error case. Is it true?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Bool is algebra <1, 0, +, *> or more familiar <T, F, |, &> (let’s ignore other operations). We are talking about semantics and not TYPE safety. Semantic is not here <T, F>, semantic is here: <|, &>. You can use Right for negative branch processing if you have only types. Type system can not save you from such “bug”. But operational model – can. Semantic of Either is here: < (>>=), return, fail >. Operation “>>=” forces you to treat Right for positive case (otherwise, your code mixing with other Eithers will have strange behaviour). The same with Bool, short-circuit operations describe semantic and force you to use True for happy-ways:<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span lang=EN-GB style='font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span lang=EN-GB style='font-family:Consolas'>e1 || e2</span><span style='font-family:Consolas'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>e2 will be evaluated only if e1 leads to false. In Bash: command e2 will be executed only if e1 fails (no False, any number =/= 0). The semantic is defining by operations, not types (operations “interpret” values and are linked with semantics), and they are similar in case of Either and Bool. So, <b>Bool type is not less safe then Either</b>. Changing of convenient leads to the same problems in both cases: strange behaviour.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Problem with Haskell is that it’s imperative and not declarative language. Haskell can not work with “behaviour”, behaviour can not be “lifted” to type system which lives at compile-time only. If type-checker passes – all is good. So, “pure $ print 1” is right in Haskell but mostly it’s error. IMHO root of the problem is more deep than talking about types.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>The root of the problem is that imperative nature of Haskell leads to missing term “evaluation to something”. Haskell program is not evaluated expression and in the same as in Java or C: it is IO action. But in Prolog every piece of code is evaluated to TRUTH or to FALSE. Each sentence is a goal which can be achieved and becomes a fact or can not be – and becomes lie. So, if you inverse semantic in Haskell – program is compiled although with strange behaviour but in Prolog program become lie. Prolog evaluation model has clean definition in run-time too, not only at compile-time. Execution of Prolog program is a CHECK: is it truth or lie? Strange behaviour of Haskell == lie in Prolog (at run-time). You will get answer “No.” (for example). It’s dialog with MU-TH-UR 6000 or HAL-9000 </span><span lang=EN-GB style='font-family:"Segoe UI Emoji",sans-serif'>😊</span><span lang=EN-GB> not execution of some action.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:jo@durchholz.org">Joachim Durchholz</a><br><b>Sent: </b>6 июля 2018 г. 23:36<br><b>To: </b><a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br><b>Subject: </b>Re: [Haskell-cafe] Bool is not...safe?!</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Am 06.07.2018 um 22:04 schrieb Olaf Klinke:</p><p class=MsoNormal>> </p><p class=MsoNormal>>> Am 05.07.2018 um 22:39 schrieb Olga Ershova <blaze@ruddy.ru>:</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke <olf@aatal-apotheke.de> wrote:</p><p class=MsoNormal>>> Does anyone know whether the C and C++ folks are now using more informative structs as return types?</p><p class=MsoNormal>>> </p><p class=MsoNormal>>> When returning errors, they call them "exceptions".</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>True but not really.</p><p class=MsoNormal>C does not have exceptions, so C APIs have always been returning </p><p class=MsoNormal>discriminated unions.</p><p class=MsoNormal>C++ exceptions tend to be used in different ways, sometimes like Olga </p><p class=MsoNormal>says, sometimes differently.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Quite so. One might say that the equivalent of try...catch blocks in Haskell is the pattern match</p><p class=MsoNormal>> </p><p class=MsoNormal>> case (action :: Either err a) of</p><p class=MsoNormal>> Right result -> ...</p><p class=MsoNormal>> Left err -> deal_with err</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That's kind of how "checked exceptions" in Java work: You declare them </p><p class=MsoNormal>in the function signature.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> But what keeps bugging me about exceptions is this: When working with libraries having nested dependencies, is there a way of knowing the complete set of exceptions that might be thrown by a block of code?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So for checked exceptions you know what may go up.</p><p class=MsoNormal>I.e. it's really equivalent to pattern matching.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>"Unchecked" exceptions are not declared.</p><p class=MsoNormal>I.e. you can use them as untyped pattern match.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> It is generally considered bad style to write a catch-all. Instead, only catch the exceptions you know how to deal with. But if I don't know</p><p class=MsoNormal>what can be thrown, then I can not make my code bullet-proof. The</p><p class=MsoNormal>explicit return type seems the clearer approach to this problem.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Not generally actually.</p><p class=MsoNormal>At the top level, you do indeed catch all exceptions, as a signal that </p><p class=MsoNormal>the called computation failed.</p><p class=MsoNormal>Typical reactions to that are:</p><p class=MsoNormal>- Abort the program.</p><p class=MsoNormal>- Log the error and wait for the next request (background programs).</p><p class=MsoNormal>- Report an error message to the user (interactive programs).</p><p class=MsoNormal>- Retry (a useful strategy if nondeterminism is involved).</p><p class=MsoNormal>- Fall back to a simpler strategy (for really large software systems).</p><p class=MsoNormal>Some design philosophies do this not just at the top level, but at each </p><p class=MsoNormal>intermediate level. Some systems are built using "monitor layers", </p><p class=MsoNormal>modules that do this kind of subtask monitoring and report an exception </p><p class=MsoNormal>only if retrying or falling back didn't work.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Regards,</p><p class=MsoNormal>Jo</p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>Haskell-Cafe mailing list</p><p class=MsoNormal>To (un)subscribe, modify options or view archives go to:</p><p class=MsoNormal>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</p><p class=MsoNormal>Only members subscribed via the mailman list are allowed to post.</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>