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

[Zoltan Somogyi]

On Sat, 31 Oct 2015 17:02:32 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > 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_.

By that, do you mean that the diff is ok, provided we also document
the new limitation?

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

I am not sure about a flat "can't be resolved", but I certainly agree with
"can't be resolved without massive pain".

Zoltan.