[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