[m-rev.] Mail delivery broken at mercurylang.org

[Volker Wysk]

Hi, Mark!

Am Dienstag, dem 18.11.2025 um 10:29 +1100 schrieb Mark Brown:
> Hi Volker,
> 
> On Wed, Nov 12, 2025 at 5:24 PM Volker Wysk <post at volker-wysk.de> wrote:
> > 
> > Am Dienstag, dem 11.11.2025 um 13:13 +1100 schrieb Mark Brown:
> > > There are plenty of times when I've been asked why I think Mercury is
> > > good, particularly by people who consider OO-design to be good, and
> > > who consider "declarative programming" to be an idealistic concept
> > > that has worn a bit thin. I'd like to give such people a more
> > > pragmatic answer.
> > 
> > Mercury can be seen as a form of declarative programming that actually
> > works.
> > 
> > To the ones which are fond of object oriented programming, I'd say that
> > Mercury isn't object oriented, but it provides most of the abstraction
> > concepts that OOP provides. It's just that you don't have all of them at
> > the
> > same time, which might be a good thing. But I'm not very sure here.
> 
> The key idea, I think, is that restricting what people can write can
> be a good thing, because it can help the people who have to read it.
> The more flexibility someone has in writing a module, the fewer
> assumptions someone reading the code can make when trying to
> understand it. It's easier to understand code if you know in advance
> that it doesn't have side effects, for example.

That's surely true. But what the language provides also shapes how you
structure the problem, and - of course - the code you write. You think in
the concepts of the programming language, all the more the closer you are to
the actual code. 

This is pretty obvious, when comparing programs written in, for instance, 
Mercury, Haskell and Java. They are all Turing complete, but you will
encounter completely different ways of programming.

Of course you can implement abstractions not present in a language in
another, by introducing boilerplate code. Such as done in the GNU glib
library, which implements a form of OOP, even though it is written in plain
C. But this isn't suggesting itself.

> > You can do OOP-like things with Mercury, such as by using existentinal
> > types
> > and type classes. But I haven't found a way yet, to emulate class
> > hierachies/inheritance (for catching exceptions). Perhaps more OOP could
> > be
> > done with some boilerplate code.
> > 
> > > 
> > > > 
> > > > Logic programming is more universal than functional programming.
> > > > This
> > > > can be
> > > > seen at the fact that functional programming can relatively easy
> > > > been
> > > > added
> > > > to a logic language. Just transalte a function f(a,b,c) = x to a
> > > > predicate
> > > > f(a::in, b::in, c::in, x::out). In the opposite direction, it should
> > > > be
> > > > much
> > > > harder.
> > > 
> > > I imagine that a typical Haskell programmer would point to the List
> > > monad as an alternative to backtracking, and might mention laziness at
> > > some point. One might also ask whether universality is even the
> > > question, given that they are Turing complete languages.
> > 
> > Universality doesn't mean Turing completeness here. It means, how
> > directly
> > you can express your ideas.
> 
> Programmers need to comprehend a lot of code, and formulate the ideas
> that they need to express. Surely expressing those ideas once
> formulated is the easy part, isn't it? Hence one might also ask
> whether expressiveness is the question.

See above.

> > > Not that I disagree with you on the facts, that's not the point. I'm
> > > just questioning what kind of argument should be made on the home
> > > page.
> > > 
> > > > 
> > > > Logic is more fundamental than functions (or lambda calculus), in
> > > > mathematics.
> > > > 
> > > > Logic is closer to human thinking (or even to thinking in general).
> > > > Or,
> > > > at
> > > > least to the logical part of human thinking.
> > > 
> > > That makes sense to me, insofar as logic is intended to be a model of
> > > human reasoning. One might ask which logic, though. Classical? Does it
> > > have to be Horn clauses? And is our audience trying to model human
> > > thinking, or are they trying to model computation?
> > 
> > Both at the same time...
> 
> When I'm thinking about what a program does once it produces a result,
> I usually imagine a big set of procedure calls with all the possible
> inputs and outputs filled in, like a multiplication table. Classical
> logic models that in a very direct way.
> 
> When I'm thinking how the program computes its result there's lots of
> things to consider, like time and space complexity, data flow, heap
> churn, scalability, security, you name it. I have a plurality of ways
> of dealing with these considerations, and I don't expect (or want) to
> find one complete model for everything.
> 
> It's a characteristic of logic programming that the code itself has a
> close resemblance to the classical model. To me, the amazing thing
> about the logic programming paradigm is that there even exists such a
> direct model that really does help with the hard parts of programming
> like understanding code and formulating ideas. The more usual case
> with programming languages is that there's no really straightforward
> way to separate the "what" from the "how".
> 
> Like I said, I think we're in agreement on the facts of the matter.
> But I believe we can put forward an argument that doesn't stem from
> authority, and makes fewer a priori assumptions about what the users
> already think.

These four paragraphs deserve a reply, but I'm not done yet.

> 
> Cheers,
> Mark
> 
> > 
> > > 
> > > > You can transform your ideas to
> > > > code more directly.
> > > 
> > > I agree with this, although I was framing it as compositionality. A
> > > chunk of Mercury code looks like a complete definition of something,
> > > as long as you keep in mind how the variables are quantified.
> > > Furthermore, you can readily "slice" the code in your own mind while
> > > reading it, to just consider the parts of a predicate that are
> > > relevant to whatever question you have. In practice I have found this
> > > to be a massive advantage in reading and understanding code, including
> > > my own code.

After I made ChatGPT translate this paragraph (and after telling it to be
close to the original), I comprehend what you are saying. Before that, I
tried it with dictionaries, but didn't have much luck.

You are very reflective about the way you think when you program. I will try
to adopt the same perspective and also make use of compositionality to
understand code.

Cheers,
Volker