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

[Volker Wysk]

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.

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