[m-users.] Inst problem

[Mark Brown]

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