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

[Zoltan Somogyi]

On Thu, 18 Jul 2019 21:49:03 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > 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

Yes, those are exactly the tests I listed.

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

OK, I will add a test for that and adjust the affected test cases, unless ...

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

... by this you mean that you think solver types *in general* are not useful anymore,
and could be removed from the language.

While solver type definitions in interfaces are a minor problem for me when working
on interface files, the presence of "any" insts would make my future task of implementing
constraint based mode analysis (using propagation, not ROBDDs) *significantly* harder,
and removing solver types from the language would eliminate "any" insts as well.

Obviously, this would be a much bigger step than banishing solver types only from interfaces,
and it would need a transition period as well as something like "a guide to implementing
constraint solvers without solver types" document added to the website. I didn't see it
from up close, but my impression was that over time, the G12 project used solver types
and "any" insts less and less over time, as the semantic and other problems became
apparent, with the deletion of auto-initialization being one example.

Any opinions?

For the time being, I added back an updated form of the prohibition against solver
types in the interface, as shown by the attached diff.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.solver
Type: application/octet-stream
Size: 1856 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190718/bb452f9e/attachment.obj>