[m-rev.] for possible review: tidying up reference manual

[Zoltan Somogyi]

On Thu, 18 Jul 2019 20:20:51 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> My immediate reaction to that was: aren't solver types *always* supposed
> to be abstract?  I then looked back over the comments on the mailing
> lists when the were first introduced (in their current form) and I don't
> think the question was addressed.
> 
> I haven't checked, but I'm pretty sure that when we used solver types
> in G12 all of them were abstract; what's the use case for allowing
> them to be defined in the interface?

I wouldn't know; I have never used solver types myself. That is why I
specifically asked for feedback about that part of the change.

However, there are several test cases that DO have non-abstract solver types
in the interfaces of modules; their writers, or the writers of the original code
that was cut down to make the test case, seem to have thought it worthwhile.
Examples include valid/solver_type_bug*.m, invalid/any_mode.m, and invalid/
foreign_solver_type.m. For the tests in invalid, the expected error messages
are NOT about a nonabstract solver type in the interface.

My objective in commenting out that paragraph was to make the manual
match the compiler's current behavior. However, that can also be done
by putting the paragraph back in and changing to compiler to prohibit
nonabstract solver types in interfaces. That would require changes to the
above test cases, but would actually make my work on interface files
somewhat easier.

By the way, is Opturion using solver types? Your phrasing seems to imply
otherwise.

What do other people think, especially people who have worked with
solver types?

> The other changes look fine BTW.

Thank you.

Zoltan.