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

[Julien Fischer]

Hi Mark,

On Mon, 3 Nov 2025 at 19:07, Mark Brown <mark at mercurylang.org> wrote:
>
> 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.

The existing description, bar a few minor edits, is what has been there
since almost the beginning.  It could certainly use an update.

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

We should probably include a page on the website about Mercury use
in industry.  I can certainly write up something about what we use it
for at Opturion.

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

It's really only built in Herbrand constraint solving that Prolog offers over
Mercury.  For other constraint domains (e.g. FD, MIP), most (although not all)
Prolog implementations just do what we do, call an external library.
(The constraint solver interfacing approach used by G12, using threaded
unique and mostly-unique state, has been very successful, if its use
at Opturion over the past decade or so is anything to go by.)

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

I don't think comparing Mercury to Haskell or Prolog is all that meaningful to
most potential users.  A better comparison would be why would you use Mercury
as opposed to another general-purpose application programming language, like
Java or C#.

Julien.