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

[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.

>
> 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.

>
> >
> > 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.

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.
>
> Hmmm.... I can't say much here.
>
> Cheers,
> Volker