[mercury-users] wrapper types

Michael Day mikeday at yeslogic.com
Fri Nov 29 21:42:07 AEDT 2002


Hi,

This is a type design issue that I encounter a lot lately. Start with a
basic type class such as input stream of XML element. Then create types 
that are instances of that type class.

:- typeclass input(T) where
	[
		pred read_char(T, char, io, io),
		mode read_char(in, out, di, uo) is det
	].

:- type input_stream.
:- instance input(input_stream).

Now, describe additional functionality in another type class such as 
putback input stream or XML element with formatting properties.

:- typeclass putback(T) <= input(T) where [ ... ].

Rather than duplicate the functionality of input_stream or XML element, in 
many cases it is easier to create wrapper types that provide merely the 
additional functionality that is needed.

:- type putback_input_stream(T).
:- instance input(putback_input_stream(T)) <= input(T).
:- instance putback(putback_input_stream(T)) <= input(T).

% use putback_input_stream(input_stream)

This is fine until more than one such wrapper is involved and the number
of type classes increases, in which case the lack of modularity of the
approach starts to drag it down. What happens when you want to compose
functionality such as input, putback, seeking and line numbering? You may
not want or need all of that functionality all of the time, so making an
uber type that does all of it is not necessarily the best solution. But a
stack of many wrapper types becomes unmanageable, as each one must forward
operations it doesn't support to the one underneath, and the types must be
kept in some kind of consistent wrapping order.

Is there some linear rather than hierarchical way to compose types? So
that you can add functionality without entirely encapsulating the
underlying type?

(I don't expect an answer of "yes", but I'd be interested to know if other
people have encountered these kind of problems, and how they have
approached them. It seems that strong typing is impossible to maintain in
such a circumstance).

Thanks,

Michael

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



More information about the users mailing list