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

Mark Brown mark at mercurylang.org
Mon Nov 23 03:46:32 AEDT 2015


On Mon, Nov 23, 2015 at 12:06 AM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> On Sun, 22 Nov 2015 21:19:06 +1100, Mark Brown <mark at mercurylang.org> wrote:
>> The attached diff reverts the workaround for bug 264.
>
> Is the first item in NEWS obsolete now?

Yes. Extra diff is attached.

>
>> I think I've
>> covered all the mode system issues related to the bug, but if anyone
>> is not convinced please say so.
>
> You cannot tell such things from a diff, because the danger is that
> some code that is NOT mention in the diff is wrong.

Have I adequately explained the cause of the bug, though? Some of the
code for inst_matches_* and inst_merge was assuming that ground was
Top, but it hasn't been for quite a while. That's what I was wanted
you to be convinced about.

>
>> It also attempts to clarify the
>> reference manual, which is for review by anyone.
>
> It talks about higher order function terms "matching" the default mode,
> but it does not define what "matching" means.

That term was also in the text that was removed. :-(

I've reworded it to avoid using "matching". Also mentioned explicitly
that this doesn't apply to predicates.

> I am not objecting to committing this change, but I do
> want to be clear that this is not a *complete* solution;
> it is still overly conservative, just in a different way.

My aim is rather modest: to fix existing mode analyser code that is
known to be incorrect. I think it's worthwhile doing that even if the
problematic code is not actually reachable.

Mark
-------------- next part --------------
diff --git a/NEWS b/NEWS
index 8e5161a..89e0458 100644
--- a/NEWS
+++ b/NEWS
@@ -3,11 +3,6 @@ NEWS since Mercury 14.01.x
 
 Changes that may break compatibility:
 
-* We have enabled stricter checking of non-ground final insts to reject more
-  mode-incorrect code.  Due to compiler limitations, some code that should be
-  accepted will now be rejected.  They will require modifications to appease
-  the compiler.
-
 * We have enabled stricter checking of the requirement that a type, inst
   or a mode that is *not* exported from a module may not be used in the
   declarations of entities (such as predicates and typeclasses) that *is*
diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
index bbd02c0..89da817 100644
--- a/doc/reference_manual.texi
+++ b/doc/reference_manual.texi
@@ -4496,10 +4496,14 @@ we assume that it has the default higher-order function inst
 @samp{func(in, @dots{}, in) = out is det}.
 
 As a consequence of this,
-a higher-order function term that does not match this default mode
-cannot match the Mercury @code{ground} inst.
-If it did, the term might later be called with the default mode,
-which would be unsound.
+a higher-order function term can @emph{only} be passed
+where a term with no higher-order inst information is expected
+if it can be passed where a term with the default higher-order function inst
+is expected.
+Higher-order predicate terms can always be passed to such a place,
+but note that there is little value in doing so because there is no
+default higher-order inst for predicates
+therefore it will not be possible to call those terms.
 
 Mercury also provides builtin @samp{inst} values for use with solver types:
 


More information about the reviews mailing list