[m-rev.] diff: minor ml_optimize.m improvements

[Julien Fischer]

Hi Zoltan,

On Mon, 16 Jan 2017, Zoltan Somogyi wrote:

>
> On Wed, 11 Jan 2017 14:19:59 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>>> It may be useful if we add a new informational message
>>> '--inform-incomplete-switch' which prints out where this is happening.
>>
>> That is a good idea. I will look into it.
>
> I have implemented a first draft of the option proposed by Julien.
> The resulting messages (stage2/*/*.err) are attached.

Hmmm, there are more of those than I would like :-(

> I think we need to think about limiting the messages somehow.
> If a switch unifies X with (say) three function symbols of its type,
> but not with the other 97 function symbols in its type, then I think
>
> - either we should not list all the 97 other function symbols in the message, or
> - we should not generate a message in the first place.
>
> We should probably have a maximum number of function symbols
> we should print in one message (say ten, with the number being
> configurable).

The situation for foreign_enum pragmas with missing foreign values is
similar: for those we print up to the first 10 missing function symbosl
if compiling with --no-verbose-errors and *all* of them if compiling
with --verbose-errors.  (Being able to print all of them is useful
because you can cut-and-paste them into your program from the error
message.)

> We could also have a second configurable threshold: we generate a message
> for an incomplete switch only if that switch mentions at least x% of the
> function symbols the switched-on var could be bound to at the start of the
> switch. (For most switches, this will be the number of function symbols
> in the type of the switched-on variable, but it could be restricted further
> by the initial inst of the variable.)
>
> There may also be other circumstances in which we may not want
> to print a message about an incomplete switch, but I plan to look for those
> only after fixing the above.
>
> About the messages themselves: I am pretty sure we should omit
> the module qualifiers from the names of the function symbols,

The message for foreign_enum pragmas does omit the module qualifiers,
although that message also mentions the name of the type involved
and that is module qualified**.

(** although since foreign_enum pragmas for a type can only appear
in the module that defines a type it shouldn't need to be.)

Julien.