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

[Julien Fischer]

Hi Zoltan,

On Thu, 18 Jul 2019, Zoltan Somogyi wrote:

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

Solver types *are* abstract in most of the test cases that contain them.
There are a few where they are not:

    tests/valid/solver_type_bug.m
    tests/invalid/any_mode.m
    tests/invalid/foreign_solver_type.m

All of the above were originally added *before* Ralph's version of
solver types was implemented.  For the older solver type design it would
have made sense to allow them to be defined in a module interface.  In
short, I think the only reason those tests have a solver type in the
module interface was that when they were updated to the new solver type
design, the compiler didn't catch it and no one gave it a second
thought.

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

I'll have to dig out the old version of G12 and check, but as I said,
I'm fairly sure that all solver types in it were abstract.

Personally, I would have no objection to requiring them be abstract if
they are exported; I cannot see why you would want the definition
in the module interface.

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

Opturion has never used solver types.  Solver types were removed from
G12 back when we were at NICTA, several years before Opturion was thing.

Julien.