[m-users.] Announcement (aggregates module) + questions (window functions)

[Mark Clements]

Zoltan,

Thank you for your detailed explanation and for your earlier code example.

Sincerely, Mark.

Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Zoltan Somogyi <zoltan.somogyi at runbox.com>
Sent: Monday, March 6, 2023 6:09:18 AM
To: Mark Clements <mark.clements at ki.se>
Cc: Richard O'Keefe <raoknz at gmail.com>; users <users at lists.mercurylang.org>
Subject: Re: [m-users.] Announcement (aggregates module) + questions (window functions)



On Sat, 4 Mar 2023 15:26:31 +0000, Mark Clements <mark.clements at ki.se> wrote:
> As a follow-up: when should one use non-determinism and when should one use Mercury?

Sorry, I do not understand this question. Mercury supports non-determinism, so
those two things are not mutually exclusive.

> To motivate my questions: I came to Mercury because I was looking for a typed "Prolog"
> that allowed for elegant joins between relationships (essentially to replace SQL:).

Pretty much any logic programming language can be used to implement joins.
But whether a join is the right approach to solve a problem depends on the problem,
and even then, it can be (and in this case, is) a question of taste whether
a join-based approach is better than a non-join-based approach.

In your original code, what I was objecting to was NOT the nondeterminism.
What I was objecting to was

- baking the data to be operated on into the program, which made
  the program totally inflexible; and

- the use of nested lambda expressions, especially when the
  inner lambda expressions seem to be redundant.

> Zoltan's implementation for the CSV example is canonical and efficient code -
> but it is also comparatively long

Both my point and (I am pretty sure) Richard's point is that what matters
is the code's *readability*, and not its *length*.

> and uses several data structures

If those structures, including the definitions of their types, and
(in a real application) the documentation of those type definitions
help readers understand what the code is doing, which I think
was the case in my program, then these structures improve
the code, and you shouldn't *want* to replace them.

> that could be
> replaced by less efficient non-determinism.

Even disregarding the point above, why would that be an advantage?

> When is the elegance of a non-deterministic solution acceptable given its inefficiency?

This question makes the implicit assumption that a non-deterministic
solution is inherently more elegant than a deterministic solution.
I don't believe that assumption is justified. For some problems,
the assumption may be true; for other prblems, it may be false.
For this problem, both Richard and I think it is false.

As for when a less efficient solution is acceptable, the answer is
obvious: when profiling and/or analysis shows that the
inefficiency does not matter.

Zoltan.



N?r du skickar e-post till Karolinska Institutet (KI) inneb?r detta att KI kommer att behandla dina personuppgifter. H?r finns information om hur KI behandlar personuppgifter<https://ki.se/medarbetare/integritetsskyddspolicy>.


Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI's processing of personal data here<https://ki.se/en/staff/data-protection-policy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20230306/5370f318/attachment.html>