[m-dev.] dummy types with user-defined equality/comparison

[Ian MacLarty]

On Mon, Jun 05, 2006 at 04:50:48PM +1000, Mark Brown wrote:
> On 05-Jun-2006, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> > On Mon, Jun 05, 2006 at 04:07:44PM +1000, Mark Brown wrote:
> > > On 05-Jun-2006, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> > > > I think the problem comes from the fact that dummy types are transparent
> > > > when they should be opaque.
> > > 
> > > "Opaque" is a good word.  How about:
> > > 
> > > 	:- opaque type foo ---> foo.
> > > 
> > > as a declaration?
> > > 
> > 
> > Or just:
> > 
> > :- opaque type foo.
> > 
> > Since it's a dummy type there's no need to actually define foo (indeed
> > it wouldn't be opaque any more if you did :-)
> 
> Unless it's io.state, your program will need to create one of these
> somewhere.  You'll need the constructor there, unless you write foreign
> code to fake it.
> 

But by exposing the definition of the type you're dissallowing
declarative reasoning on predicates that pretend to update the dummy
type.  I would say the better solution would be to have the compiler
generate creation and update predicates for dummy types.  These of
course would never actually exist in reality, but they complete the
illusion and make the type truly opaque.

For example if you have

:- opaque type foo.

You'd get:

:- pred new_opaque_foo(foo::uo, io::di, io::uo) is det.

and 

:- func update_opaque_foo(foo::in, foo::out) is det.

(probably with better names).

You'd probably also want an impure version of the new predicate and a
unique version of the update predicate.

Ian.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------