[m-dev.] Fwd: [m-users.] Inst problem

[Mark Brown]

Hi Volker,

On Tue, Nov 4, 2025 at 12:08 AM Volker Wysk <post at volker-wysk.de> wrote:
>
> Hi there
>
> I, as a programmer, want to have a LOGIC language. Logic programming is
> superior to functional programming, in my mind. And, of course, this applies
> even more to a logic-functional language like Mercury.

Can you explain that in concrete, objective terms? I'm not looking for
a testimonial.

>
> Volker
>
> Am Montag, dem 03.11.2025 um 19:07 +1100 schrieb Mark Brown:
> > Hi all,
> >
> > Following on from my forwarded message below, I think we could give a
> > better description of Mercury than what is currently on the home page.
> > For one thing I think we have demonstrated some of the claims made in
> > the original Mercury concept, including its use in real-world
> > programming and the "sweet spot" idea about distributed fat, so we can
> > rightfully state that. Zoltan would of course be the best position to
> > make an accurate statement on this.
> >
> > I also think we ought to be clearer about what Mercury is good at,
> > compared to cases where we think Prolog or Haskell might make a better
> > choice. For example, we could say that Mercury is for programmers who:
> >
> > - want the compositionality and logical clarity of Prolog
> > - want the pure equational reasoning of Haskell
> > - want a practical system for industry-scale projects
> > - don't mind sacrificing some of the techniques available in Prolog
> > (if you want to use complex unifications, constraint solving or
> > metaprogramming, Prolog may be a better choice)
> > - don't mind sacrificing some of the more powerful abstractions
> > available in Haskell (if you want to write a reusable library
> > interface using monads, or if you want a highly evolved type system,
> > Haskell may be a better choice)
> >
> > Does anyone else have any thoughts about this? Any objections or
> > alternatives?
> >
> > Cheers,
> > Mark
> >
> > ---------- Forwarded message ---------
> > From: Mark Brown <mark at mercurylang.org>
> > Date: Mon, Nov 3, 2025 at 2:00 PM
> > Subject: Re: [m-users.] Inst problem
> > To: Volker Wysk <post at volker-wysk.de>
> > Cc: Zoltan Somogyi <zoltan.somogyi at runbox.com>, Mercury Users
> > <users at lists.mercurylang.org>
> >
> >
> > Hi Volker,
> >
> > On Mon, Nov 3, 2025 at 1:02 AM Volker Wysk <post at volker-wysk.de> wrote:
> > >
> > > Am Sonntag, dem 02.11.2025 um 22:41 +1100 schrieb Zoltan Somogyi:
> > > >
> > > >
> > > > On Sun, 02 Nov 2025 11:08:02 +0100, Volker Wysk <post at volker-wysk.de>
> > > > wrote:
> > > > > Why won't the mode analyser propagate the results of the "Path ^ abs
> > > > > =
> > > > > yes"
> > > > > part?
> > > >
> > > > There are two separate reasons.
> > > >
> > > (...)
> > > >
> > > > Second, even after Term = functor(Field1, Field2), Field1 = yes,
> > > > which is what Term = functor(yes, Field2) expands to inside the
> > > > compiler,
> > > > in order to know that after Field1 = yes, the inst of Term has changed
> > > > as
> > > > well,
> > > > the compiler would need to keep track of aliasing information.
> > > > In this case, it would need to know that when the inst of Field1
> > > > changes,
> > > > the inst of Term's first argument also changes. This is easy to see
> > > > in this simple example, but what if e.g. Term = functor(Field1,
> > > > Field2)
> > > > was in the then-part of an if-then-else, and the Field1 = yes was
> > > > *after*
> > > > the if-then-else? The alias would hold *only* if execution took the
> > > > then
> > > > path.
> > > > And when you nest several if-then-elses and disjunctions together,
> > > > the result quickly becomes a mess.
> > > >
> > > > We did explore this issue early in the Mercury project's history. We
> > > > found
> > > > it required a large increase in code complexity, which resulted in
> > > > both
> > > > a large slowdown (alias-tracking mode analysis took more than ten
> > > > times
> > > > as long as the original version) and fragile compiler code. And by
> > > > then,
> > > > we realized that we got along well enough without it. We therefore
> > > > considered
> > > > the price of alias tracking not worth paying.
> > >
> > > Maybe the price is not worth paying. But it's clearly counter-intuitive.
> > > You
> > > have to learn to think like the compiler, rather than think in terms of
> > > your problem...
> > >
> > > My original idea (of introducing the abs_path inst) and the answers I
> > > got
> > > here, made me realize that using inst subtyping is not a good idea after
> > > all.
> >
> > It's stretching my memory, but I believe Zoltan may have suggested
> > this to Fergus several decades ago :-)
> >
> > Sardonic humor aside, I think the Mercury team has contributed to the
> > current situation by not being clear about the scope of the Mercury
> > project. The scope has changed over the years, as Zoltan's above
> > comment indicates, but the message on the home page (for example)
> > hasn't changed in any way that would communicate that. We ought to do
> > a better job in this regard.
> >
> > One of the core hypotheses of the Mercury project in its academic days
> > was that with a relatively small compromise to expressiveness an
> > implementation could remove a lot of "distributed fat", which is to
> > say runtime costs that you have to pay even when not using the
> > features they support. So there should be a kind of sweet spot in the
> > language design space which provides for a good tradeoff between
> > expressiveness and efficiency, aimed at real-world software
> > development.
> >
> > After decades of using Mercury on industry-scale projects, I'd say
> > this hypothesis is confirmed. In fact, we have discovered that we can
> > reduce expressiveness even more than what was originally anticipated,
> > since it turns out that there can be unintended benefits in
> > restricting what programmers can write. I think that's ultimately why
> > the Mercury implementation is more restrictive in practice than the
> > language definition suggests.
> >
> > Cheers,
> > Mark
> >
> >
> > >
> > > Thanks for the replies.
> > >
> > > Happy hacking,
> > > Volker
> > > _______________________________________________
> > > users mailing list
> > > users at lists.mercurylang.org
> > > https://lists.mercurylang.org/listinfo/users