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

[Julien Fischer]

On Thu, 18 Jul 2019, Zoltan Somogyi wrote:

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

...

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

If there is a desire to support a CLP style constraint modelling
interface in Mercury, then they are useful.  For G12, it was originally
intended that Mercury be used as a CLP style modelling language *by
humans*.   As it turned, we ended up using Mercury mostly as a solver
implementation language and as a compilation target for other languages
(e.g. Zinc).  Using the CLP style approach for those two use cases
turned out to be a PITA.  Part of that was down to the fact that solver
types were being developed alongside the rest of G12 and were not
particulary stable for a long time.  Another was that solver types
pretty much force your implementation layer to be impure.  (The
so-called model_ui approach that replaced solver types in G12, uses
threaded unique and mostly-unique state and the resulting code is nearly
always pure.)

Cynics might suggest CLP is not as useful as its proponents think
and doesn't scale to building large systems very well ;-)

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

Actually, solver types were removed from G12 in one fell swoop.  As I
mentioned above, the real issue was that Mercury's role within G12
shifted.

> Any opinions?

I had a chat with Leslie this morning; so far as Opturion is concerned
we are not currently using solver types and are not planning to do so
again.  From our point of view if the tradeoff for getting rid of "any"
insts is a mode checker that fixes the issues around unique modes
(particularly ui and mui; the former of which we use extensively and the
latter of which we would like to use but is completely unusable) then
that would be well worth it.

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

That looks fine.

Julien.