[mercury-users] Modular data-abstraction and mostly unique modes.

[Henk Vandecasteele]

Fergus Henderson wrote:
> 
> On 06-Jan-1998, Henk Vandecasteele <Henk.Vandecasteele at cs.kuleuven.ac.be> wrote:
> >
> > I would like to build a finite domain solver. And given the
> > modules in Mercury I want to build an abstract type.
> >
> > Unfortunately this seems incompatiable with Mostly unique modes.
> 
> It's not really mostly unique modes which are the problem;
> the same problem arises with any use of complicated modes
> for abstract data types.
> ...

> The work-around is to just make the inst concrete, and document that
> it is intended to be abstract.
> 
>         :- module fd_solver.
>         :- interface.
> 
>         :- type fd_store.
>         % :- inst mostly_uniq_fd_store.  % abstract
>         :- mode fd_store_muo :: free -> mostly_uniq_fd_store.
>         :- mode fd_store_mui :: mostly_uniq_fd_store -> mostly_uniq_fd_store.
>         :- mode fd_store_mdi :: mostly_uniq_fd_store -> mostly_dead.
> 
>         /* THIS IS REALLY PART OF THE IMPLEMENTATION, NOT THE INTERFACE */
>         :- import_module array.
>         :- inst mostly_uniq_fd_store = mostly_uniq_array(ground).
> 
>         :- implementation.
>         :- type fd_store == array(global_data).
> 
This solutions works fine, Thanks.
Anyway, maybe I'm missing some points, but I find the mode-system
when doing more complicated things like above difficult to use.
I for instance believe that instantiation information and uniqueness
information is something different. And glueing them together makes 
things unclear. 

> > Which I don't like.
> 
> Yes, it's not the most elegant solution imaginable, I'm afraid.
> But it's just inelegant, not unworkable.  The fact that the type
> is abstract prevents anyone from making use of the implementation details.
Your completely right.


Before I forget, I think there is a typo in the manual.

The section on mostly unique modes says:

...
Mercury also provides "mostly unique" modes. The insts
`mostly_unique' and `mostly_dead' are equivalent to `unique' and `dead',
except that only references which will be encountered during forward
execution are counted - it
is OK for `mostly_unique' or `mostly_dead' values to be needed again on
backtracking. 

Mercury defines some standard modes for manipulating "mostly unique"
values, just as it does for
unique values: 

% mostly unique output
:- mode muo :: free -> unique.

% mostly unique input
:- mode mui :: unique -> unique.

% mostly destructive input
:- mode mdi :: unique -> dead.
...

I think unique and dead should be mostly_unique and mostly_dead.

Henk