[mercury-users] abstract types.

[Thomas Conway]

Hi all [again]

Here is the next performance issue that I'm up against in my yacc clone.

I have a type:
	:- type lr1item --->	item(prodNum, dot, symbol).
	:- type prodNum	== int.
	:- type dot	== int.
	:- type symbol	--->	end ; (string/int). % (Name/Arity)

The sets I was talking about before, and the keys that I was using
are of type lr1item. If I make some assumptions about the number
of productions and token types, I could encode the three things
in a single 32 bit int. This would have a couple of obvious advantages:
	- less memory, since a single int isn't boxed
	- quicker comparisons (especially with type specialization)

Now, at the time when I start constructing lr1items the set of symbols
is fixed, so I can number them, and the range of prodNum and dot are
known so safety can be assured easily enough. Assuming I can use 12
bits each for the prodNum and the encoding of the symbol and 8 for dot
(which seems reasonable enough - at least for the sake of the argument),
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?

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