[m-users.] Inst problem

[Volker Wysk]

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.

Thanks for the replies.

Happy hacking,
Volker