<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;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:393167495;
mso-list-type:hybrid;
mso-list-template-ids:-613646450 -1 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style></head><body lang=RU link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-GB>@Olaf Hello, you are right. Prolog allows side-effects, which means that you has predicates which is not “pure”. Today, after “pure” functional programming fashion, there is fashion of pure declarative programming too </span><span lang=EN-GB style='font-family:"Segoe UI Emoji",sans-serif'>😊</span><span lang=EN-GB> You define nature of predicates with determinism categories but “variables” nature with +/- notation (if variable is “output” only then it’s not pure predicate, for example, “X is Y + 5” is not pure because it’s functional but not declarative, ie, it’s evaluation but not relation). Mercury has “!” annotation, which is close to linear types I suppose (am I right?). Idea was side-effects is coded as input-output variable which is changing (state of external world). Unfortunately, I learned Prolog when I was student... <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>When we are talking about truth, probably truth, etc, I think we mean <a href="https://www.mercurylang.org/information/doc-latest/mercury_ref/Determinism-categories.html">https://www.mercurylang.org/information/doc-latest/mercury_ref/Determinism-categories.html</a>. In Prolog we apply restrictions/relations to answer to get more strict answer. It’s linked with declarative nature: no evaluation but some kind of DSL to barrier answers. Sure, it’s not strict definition or something like this </span><span lang=EN-GB style='font-family:"Segoe UI Emoji",sans-serif'>😊</span><span lang=EN-GB> My intuition is like Prolog evaluation can be imagine in Haskell terms like some logic monad on top level instead of IO monad (main :: SomeLogic (), for example). Btw, how works Curry? And another my intuition is that it’s possible in Haskell with some (new?) monad. I will observe your examples, thanks a lot!<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>@Joachim.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Hello again. Let’s talk about Haskell and not persons. I suppose that my not good English may lead to misunderstanding. Excuse me, in this case. If you allow me, I would like to show reasons why I said “imperative” and not declarative.<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>In Haskell I can write:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'>factorial 0 = 1<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'>factorial n = n * factorial (n - 1)<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>I can call it: factorial 5 => 120.</span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>And often I meet in Web similar examples with note: “You see – Haskell is declarative language, it really looks declaratively”. IMHO it looks only (you can check Erlang syntax, which is similar to Prolog even, but Erlang is not declarative language). Let’s try the same in Prolog.</span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'>factorial(0, 1).<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'>factorial(N, F) :-<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'> N #> 0,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'> N1 #= N - 1,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'> F #= N * F1,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span style='font-family:Consolas'> factorial(N1, F1).<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>I can call it: factorial(5, X) => X=120.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB>But also: factorial(X, 120) => X=5.<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>We see principal difference:<o:p></o:p></span></p><ol style='margin-top:0cm' start=1 type=1><li class=MsoNormal style='mso-list:l0 level1 lfo1'><span lang=EN-GB>In Haskell we map inputs (arguments) to result. In Prolog we define not mapping but <b>relation</b>, which is <b>bi-directional</b> while Haskell is <b>one-directional</b>, like C, Java, etc. We can find also arguments from result in Prolog.</span><o:p></o:p></li><li class=MsoNormal style='mso-list:l0 level1 lfo1'><span lang=EN-GB>In Haskell like in any imperative language we describe exact algorithm/solution. We define <b>HOW</b>. In declarative language we define <b>WHAT</b>: we <b>restrict result</b> and don’t know actually how it will be evaluated.</span><o:p></o:p></li><li class=MsoNormal style='mso-list:l0 level1 lfo1'><span lang=EN-GB>In Haskell all is evaluated as you wrote code. Exactly. No magic. But in Prolog we restrict some <b>solver</b> to find answer (or answers). In the example this solver is called CLP(FD). Sure, there are other solvers. Modern Prolog systems contain a lot of solvers, expert system engines, etc, etc. So, Haskell has not solvers/engines. Prolog has. Prolog is DSL for solvers. Interesting analogue is SQL as DSL for RDBMS</span><span lang=EN-GB style='font-family:"Segoe UI Emoji",sans-serif'>😊</span><o:p></o:p></li></ol><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>If we want to achieve the same magic in Haskell, we must write such solver explicitly (ie. “how”).<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>Another interesting speculation about real nature of Haskell is List monad. We often see “Haskell is declarative because it has backtracking” with attached some example of List monad/do/guard. But we can say that Python is declarative because it has permutations in its itertools module which allows to solve similar tasks. We understand that List monad is not backtracking, and “guard” is similar to Smalltalk “ifTrue” – no magic, no real backtracking. But like Python itertools can be used to solve some logic tasks in bruteforce/permutations style (as many other modern languages with sequences, F#, for example).<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>You said that “imperative” term is based on term of side-effects. May be I’m seriously wrong, but please, correct me in this case. IMHO side-effects are totally unrelated to imperative/declarative “dichotomy”. For example,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span lang=EN-GB style='font-family:Consolas'>int sum(int a, int b) { return (a + b); }<b><o:p></o:p></b></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>I don’t see here side-effects. I have not problems to write all my C code in such style. Without any side-effects. Also I find “pure” functions in D language, “function” keyword in Pascal and Basic. But also I see<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span lang=EN-GB style='font-family:Consolas'>main :: IO ()<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>in Haskell. So, I don’t think side-effects are relative to declarative/imperative dichotomy at whole. When I was student, criteria of declarative/imperative was: functional, procedural, OOP languages are imperative, due to one-directional evaluation/execution and you code HOW to be evaluated, but declarative is bi-directional, you code relations (WHAT), between predicates and apply some restrictions.<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>I am surprised that there is another classification: based on side-effects. Please, correct me, where I’m wrong and if you can do it without such emotion – I will be very glad to get new knowledge.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>PS. Out of scope is declarative DSLs written in imperative languages: like Scons Python build system. Sure, there are a lot of similar Haskell libraries/tools. IMHO more correct is to say “Scons has declarative Python-based DSL, but not Python is declarative itself”.</span><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>7 июля 2018 г. 11:17<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 07.07.2018 um 07:15 schrieb Paul:</p><p class=MsoNormal>> By the way, there are a lot of articles why checked exceptions are bad </p><p class=MsoNormal>> design (more problems than benefit).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That's because exceptions disrupt control flow.</p><p class=MsoNormal>If they're used as an alternative to pattern matching, i.e. thrown only </p><p class=MsoNormal>in tail position and always either fully handled or rethrown unchanged, </p><p class=MsoNormal>then they're fine.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I.e. checked exceptions are bad because they make it easy to construct </p><p class=MsoNormal>bad design. Unchecked exceptions can be abused in the same way but there </p><p class=MsoNormal>seem to be psychological reasons why this isn't done so often.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> More interesting for me is this snippet:</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>> </p><p class=MsoNormal>> Somebody says me that to use Bool in such way is “not safe” because no </p><p class=MsoNormal>> way to know what does “True” returning from “action” mean. Success or </p><p class=MsoNormal>> failure? But with some ADT (Success|Failure) code is more Haskellish and </p><p class=MsoNormal>> safe.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Terminology N.B.: (Success|Failure) is not an abstract data type (ADT). </p><p class=MsoNormal>It's pretty much the opposite of abstract.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> But is it true? We are talking about semantics, not type-safety because </p><p class=MsoNormal>> type-checker passes both cases (positive branch under False/Failure, </p><p class=MsoNormal>> negative branch under True/Success). But the same with Right/Left: </p><p class=MsoNormal>> nothing says you to use Right for positive and Left for error case. Is </p><p class=MsoNormal>> it true?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There's no good way to use Bool as the type of action, so the point is moot.</p><p class=MsoNormal>Of course you can reconstruct action's type to be a struct consisting of </p><p class=MsoNormal>a Bool, a SuccessResult, and a FailureResult, but that's just awkward so </p><p class=MsoNormal>nobody is doing this.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Bool is algebra <1, 0, +, *></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Let me repeat: the algebraic and mathematical properties of Bool are </p><p class=MsoNormal>irrelevant.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Problem with Haskell is that it’s imperative and not declarative </p><p class=MsoNormal>> language.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Haskell isn't imperative.</p><p class=MsoNormal>I.e. it matches almost none of the definitions for "imperative" that I </p><p class=MsoNormal>have ever seen.</p><p class=MsoNormal>It matches a substantial percentage of the definitions for "declarative" </p><p class=MsoNormal>actually, but not enough of them that I'd instinctively say it is really </p><p class=MsoNormal>declarative - others with a different set of definitions encountered may </p><p class=MsoNormal>feel differently.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> The root of the problem is that imperative nature of Haskell leads to </p><p class=MsoNormal>> missing term “evaluation to something”.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The most compact definition of "imperative" that I have seen is </p><p class=MsoNormal>"computation progresses by applying side effects".</p><p class=MsoNormal>By that definition, the ability to distinguish evaluated and unevaluated </p><p class=MsoNormal>expressions is irrelevant.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Haskell program is not evaluated</p><p class=MsoNormal>> expression and in the same as in Java or C: it is IO action. But in </p><p class=MsoNormal>> Prolog every piece of code is evaluated to TRUTH or to FALSE. Each </p><p class=MsoNormal>> sentence is a goal which can be achieved and becomes a fact or can not </p><p class=MsoNormal>> be – and becomes lie.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Wrong terminology. Nothing in a computer is a lie.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Prolog works by turning stuff into either tautologies or contradictions.</p><p class=MsoNormal>A lie is something entirely different: a statement that intentionally </p><p class=MsoNormal>contradicts reality. Programming language semantics does not have </p><p class=MsoNormal>intention; programs may have state that matches or contradicts reality, </p><p class=MsoNormal>but take this message which isn't a lie but still does not match any </p><p class=MsoNormal>reality because no sheet of paper with these glyphs ever existed (there </p><p class=MsoNormal>may be in the future if somebody prints this message, but that doesn't </p><p class=MsoNormal>turn this message from a lie into a truth).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Please, get your terminology right. If you keep working with "almost </p><p class=MsoNormal>right" terminology in your head, you will continuously "almost </p><p class=MsoNormal>misunderstand" whatever you read, leading you to conclusions which are </p><p class=MsoNormal>almost right but take a huge amount of effort to clean up. People who </p><p class=MsoNormal>know the concepts and the terminology will find it too tiresome to talk </p><p class=MsoNormal>with you because it is all about educating you (which is not the right </p><p class=MsoNormal>level to talk with a person anyway), and will eventually drop out of </p><p class=MsoNormal>discussions with you; the only persons who talk to you will be those who </p><p class=MsoNormal>happen to have similarly vague ideas, placing you in an echo chamber of </p><p class=MsoNormal>ideas that lead nowhere because everything is subtly wrong.</p><p class=MsoNormal>Just saying. I'm not going to force anything on you - but I find that </p><p class=MsoNormal>this message is entirely about terminology correction and almost nothing </p><p class=MsoNormal>about the topics that really interest you, which means it's been mostly </p><p class=MsoNormal>a waste of time of both of us.</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>