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

[Julien Fischer]

Hi Zoltan,

On Fri, 30 Oct 2015, Zoltan Somogyi wrote:

> On Fri, 30 Oct 2015 15:03:52 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>> I take that to mean that it is allowable when the higher-order inst
>> information is preserved.
>
> What happens if it is preserved for a while, and then it is lost?
> Uses during the first period are fine, uses during the second period
> cause a crash. At the moment, we have no way to prevent that loss
> of information. Maybe we should consider changing the rules to
> outlaw not putting such nonstandard signature functions into terms,
> but losing the higher inst info on terms containing higher order values.
> Unfortunately, I am pretty sure that implementing that would be
> a massive pain with the current mode system implementation.

For now, as it certainly isn't acceptable for the compiler to be
accepting programs that cause segmentation faults, we need to go with
Peter's suggestion: disallow the construction of terms with a
non-default mode function _as a limitation of the current
implementation_.

The larger language design issue raised here can't be resolved with the
current implementation of mode checking.

>>  In particular, I can't see why
>> tests/valid/ho_func_call is not fine, since the code in that test seems
>> to preserve the higher-order inst information.
>
> Yes it does preserve it. The problem is that the ho_func_call test case
> is in other respects  a horrible piece of code in terms of programming
> style (it is WAY overcomplicated), and thus it is not, to my mind,
> a persuasive argument for keeping this practice legal.

The compiler doesn't care about programming style, only whether a program
is valid Mercury or not.  With this change, the compiler will say that
ho_func_call is not valid Mercury, even though the reference manual says
otherwise.

> There may be other pieces of code out there which ARE persuasive
> arguments to that end. I don't know of any, but you guys may.
> That is why I asked for comments on this.

I'm not aware of any.  Constructing terms with higher-order arguments,
whether predicates or functions, is pretty rare in any case.

> Another possibility is to make the code I just added subject to a new
> option, say --allow-nonstandard-funcs-in-terms. If not given, we would
> disallow both ho_func_call and default_ho_inst, which would be too tight.
> If given, we would allow both, which would be too loose. If we cannot
> (a) define *exactly* what operations are safe with nonstandard signature
> functions in terms, and (b) implement that definition, that may be the
> best we can do to satisfy everyone.

I don't think adding a new option is necessary; all that needs to be done
is to update the reference manual to document the limitation.

Julien.