[m-rev.] for review: don't allow nondefault mode functions in terms

Zoltan Somogyi zoltan.somogyi at runbox.com
Mon Nov 2 07:22:35 AEDT 2015

On Mon, 2 Nov 2015 06:17:10 +1100, Mark Brown <mark at mercurylang.org> wrote:
> But this is not the problem I am facing right now. There are not that
> many predicates in total that are needed; we only have around a dozen,
> and that is counting the meanings of all terms (like unique and any),
> plus combinations of terms.

Plus the places that don't call any of these predicates, but do tests
on insts via simple unifications.

> As a step in this direction I have separated inst_match.m into two
> modules. This significantly reduces its coupling with the rest of the
> compiler, and should help in future changes to inst_match.m, whatever
> happens. Diff is attached; I think only the log message needs review.

I had a look at the log message, and it is fine. Go ahead and commit it.

> No, although the past 24 hours has convinced me to accept your patch
> for the time being. ;-)

OK. I will post a proposed diff to the reference manual for review.

> Well, I agree with pushing such information from the type system to
> the mode system, although I don't agree that it helps with the
> terminological problem.

Agreed. The proposal was to help with the implementation,
not with terminology.

>  You'll still have the same binary
> relationships between insts to come up with a name for (matches, etc),
> but you'll have an additional one for types, too.

Yes. The terminology problem is like toothpaste: if you
squeeze it out of HERE, it moves THERE instead of disappearing.


More information about the reviews mailing list