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

[Zoltan Somogyi]

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?

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

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

> The new test case
> demonstrates the point from the previous paragraph.

The test case demonstrates the ambiguity of "matching".
There is, I think, a valid argument for allowing the program
to put  subfoo into a foo term: it accepts every term that
the default mode of "func(t) = t" requires it to accept.
Yes, it declares that there are some values in the range type
that it won't ever return, but some functions with the
default mode will also fail to ever return some value
of the range type. The only difference is that subfoo's
mode states this *explicitly*.

There is plenty of research in functional and imperative
languages showing that subtype restrictions on input and
output arguments should be treated differently. However,
I don't know of any research that tries to apply this
research on contravariance vs covariance to logic languages
where the same argument may be input in one mode
and output in another. For such arguments, I expect
the only sound thing to do is to require an exact match,
but I have seen no proof of that.

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.

Zoltan.