[m-users.] Inst problem

[Volker Wysk]

Am Montag, dem 03.11.2025 um 14:00 +1100 schrieb 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.

Efficiency is important for real-life projects. The most beautiful language
is doomed to fail, if it doesn't match the real-world requirements. 

However, expressiveness is (or can be) a requirement too... Maybe, if there
were available more human ressources for developing the compiler, an
efficient implementation of alias tracking would be possible... But that's
speculation for my part.

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

Good to hear that it is being used in the industry. I was getting the
impression that Mercury is slowly dying.

Cheers,
Volker