[m-rev.] diff: minor ml_optimize.m improvements
zoltan.somogyi at runbox.com
Mon Jan 16 17:41:27 AEDT 2017
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.
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
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,
but I am in two minds about whether we should force the messages
to print each function symbol on a line of its own.
Any opinions on any of this? Any proposals for names of the options
that do the configurations mentioned above?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 301314 bytes
Desc: not available
More information about the reviews