<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="auto">Zoltan,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thank you for your detailed explanation and for your earlier code example.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Sincerely, Mark.</div>
<div><br>
</div>
<div id="ms-outlook-mobile-signature" dir="auto">Sent from <a href="https://aka.ms/AAb9ysg">
Outlook for Android</a></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Zoltan Somogyi <zoltan.somogyi@runbox.com><br>
<b>Sent:</b> Monday, March 6, 2023 6:09:18 AM<br>
<b>To:</b> Mark Clements <mark.clements@ki.se><br>
<b>Cc:</b> Richard O'Keefe <raoknz@gmail.com>; users <users@lists.mercurylang.org><br>
<b>Subject:</b> Re: [m-users.] Announcement (aggregates module) + questions (window functions)</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
<br>
On Sat, 4 Mar 2023 15:26:31 +0000, Mark Clements <mark.clements@ki.se> wrote:<br>
> As a follow-up: when should one use non-determinism and when should one use Mercury?<br>
<br>
Sorry, I do not understand this question. Mercury supports non-determinism, so<br>
those two things are not mutually exclusive.<br>
<br>
> To motivate my questions: I came to Mercury because I was looking for a typed "Prolog"<br>
> that allowed for elegant joins between relationships (essentially to replace SQL:).<br>
<br>
Pretty much any logic programming language can be used to implement joins.<br>
But whether a join is the right approach to solve a problem depends on the problem,<br>
and even then, it can be (and in this case, is) a question of taste whether<br>
a join-based approach is better than a non-join-based approach.<br>
<br>
In your original code, what I was objecting to was NOT the nondeterminism.<br>
What I was objecting to was<br>
<br>
- baking the data to be operated on into the program, which made<br>
the program totally inflexible; and<br>
<br>
- the use of nested lambda expressions, especially when the<br>
inner lambda expressions seem to be redundant.<br>
<br>
> Zoltan's implementation for the CSV example is canonical and efficient code -<br>
> but it is also comparatively long<br>
<br>
Both my point and (I am pretty sure) Richard's point is that what matters<br>
is the code's *readability*, and not its *length*.<br>
<br>
> and uses several data structures<br>
<br>
If those structures, including the definitions of their types, and<br>
(in a real application) the documentation of those type definitions<br>
help readers understand what the code is doing, which I think<br>
was the case in my program, then these structures improve<br>
the code, and you shouldn't *want* to replace them.<br>
<br>
> that could be<br>
> replaced by less efficient non-determinism.<br>
<br>
Even disregarding the point above, why would that be an advantage?<br>
<br>
> When is the elegance of a non-deterministic solution acceptable given its inefficiency?<br>
<br>
This question makes the implicit assumption that a non-deterministic<br>
solution is inherently more elegant than a deterministic solution.<br>
I don't believe that assumption is justified. For some problems,<br>
the assumption may be true; for other prblems, it may be false.<br>
For this problem, both Richard and I think it is false.<br>
<br>
As for when a less efficient solution is acceptable, the answer is<br>
obvious: when profiling and/or analysis shows that the<br>
inefficiency does not matter.<br>
<br>
Zoltan.</div>
</span></font></div>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1561.6">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Times; color: #000000; -webkit-text-stroke: #000000; min-height: 14.0px}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Times; color: #000000; -webkit-text-stroke: #000000}
span.s1 {font-kerning: none}
span.s2 {text-decoration: underline ; font-kerning: none; color: #0000ee; -webkit-text-stroke: 0px #0000ee}
</style>
<p class="p1"><span class="s1"></span><br>
</p>
<p class="p1"><span class="s1"></span><br>
</p>
<p class="p2"><span class="s1"><i>När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter.
</i><a href="https://ki.se/medarbetare/integritetsskyddspolicy"><span class="s2">Här finns information om hur KI behandlar personuppgifter</span></a>.<span class="Apple-converted-space"> </span></span></p>
<p class="p1"><span class="s1"></span><br>
</p>
<p class="p2"><span class="s1"><i>Sending email to Karolinska Institutet (KI) will result in KI processing your personal data.</i>
<a href="https://ki.se/en/staff/data-protection-policy"><span class="s2">You can read more about KI’s processing of personal data here</span></a>.<span class="Apple-converted-space"> </span></span></p>
</body>
</html>