On 20-Feb-2000, Brian Boutel <[EMAIL PROTECTED]> wrote:
>
> Obviously, in general, information hiding is useful. Here, the specific
> question is about instance declarations.Is there any value in being able to
> hide them?
>
> I think the answer is no, for the following reasons:
>
> 1) There is complete control of the visibility of Classes and Types. If C
> or T is not visible at a point in the program, the visibility of the C-T
> instance is immaterial. If C and T are both visible, and the C-T instance
> is not, what have you gained? Can you give an example of when you would
> want to do this?
Well, suppose I have some type which I want to be "unforgeable",
i.e. for which client modules should only be able to create objects
of that type using the functions declared in my module's interface.
And suppose also that some of my functions are implemented using
serialization and deserialization (e.g. for distributed programming).
Now to implement this deserialization I might want to make my type an
instance of `Read' (or some similar class for deserialization), but I
don't want client modules to be able to use that interface to forge
objects of my type.
Of course there are ways of implementing that in Haskell as it stands,
e.g. by implementing my type as
:- newtype MyType = MkMyType MyTypeImp
:- data MyTypeImp = ...
and then using
instance Read MyTypeImp
rather than
instance Read MyType
But because visibility of instances is completely implicit in Haskell,
the programmer may well not even realize that the `instance Read MyType'
instance is being exported.
> 2) In terms of ADTs, Haskell allows (approximations to) ADTs by allowing a
> type to be exported without its constructors. This by itself gives you a
> sort of ADT with only one possible implementation. If you want ADTs where
> more than one implementation is possible, the mechanism is to use a Class C
> and its operators as the ADT, with various Types T as implementation types,
> and the C-T instance functions as the *public* methods. It is essential
> that they are not hidden. Of course, you can still have private methods,
> which are not exported, but these are not part of the Class.
Private instance declarations correspond to private inheritance,
not to private methods.
> 3) If you do have private instances, then a program which needs to import a
> module with such a private C-T instance is prevented from declaring another
> instance for the same C and T (under the rule that allows only one C-T
> instance per program). Suppose, for example, that there is a type of Tree,
> and you have written a module, with some good stuff that I want to use, but
> in which you declare Tree to be an instance of Ord, but don't export it.
> Then I am prevented from using Tree as an ordered type. This would be a
> disaster.
Well, you can always defined a type using Tree which _is_ an instance of Ord:
newtype OrdTree = MkOrdTree Tree
instance Ord OrdTree where ...
So I don't see this as a disaster.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
