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

[Zoltan Somogyi]

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.

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

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.

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.

Zoltan.