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

[Mark Brown]

Hi Julien,

On Wed, Nov 5, 2025 at 2:36 PM Julien Fischer <jfischer at opturion.com> wrote:
>
> 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.

The motivation page is also a bit old sounding.

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

Oops, sorry! terrible example...

I was thinking of libraries that embed very nicely, which are widely
available in prolog. Constraint solvers are one example, but I think I
meant to say embedded libraries.

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

The reason for choosing those two is that we claim to be
"logic/functional". So the points at which users would be better off
with prolog or haskell, respectively, make good indicators of the
scope of mercury. Or at least the scope of what we are claiming (with
evidence) as a success.

Does that make sense?

>
> Julien.