[mercury-users] abstract types.

[Thomas Conway]

On Mon, Jan 17, 2000 at 06:26:55PM EST, Peter Schachte wrote:
> > How should I implement an abstract form of lr1item? I'd like the interface
> > to be the same:
> > 	:- type lr1item.	% abstract
> > or
> > 	:- type lr1item == int.
> > 
> > along with:
> > 	:- func lr1item(prodNum, dot, symbol).
> > 	:- mode (lr1item(in, in, in) = out) is det.
> > 	:- mode (lr1item(out, out, out) = in) is det.
> > 
> > Or should I just make another type "encoded_lr1item" and use explicit
> > conversions?
> 
> I'd hope the simple bidirectional function version would work, so I'd
> suggest giving that a bash, and use explicity pack/unpack operations
> as a last resort.
> 

There's a bit of a problem in making bidirectional functions like this -
apart from anything else, the code for \/ing the bits together doesn't
work in the backwards mode (ie:
	lr1item(ProdNum, Dot, Sym) = Bits :-
		encode_sym(Sym, SymNum),
		Bits = (ProdNum << 20) \/ (Dot << 12) \/ SymNum.
)

Now, you can work around this by using the C interface as a layer
between the layers of Mercury - implement the two modes as pragma c_code
that calls two separate mercury preds/funcs that each implement a single
mode. This seems expensive and ugly. Perhaps it's time to allow separate
implementations of different modes of a pred/func?

-- 
 Thomas Conway )O+     Every sword has two edges.
     Mercurian            <conway at cs.mu.oz.au>
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------