[m-dev.] io streams

[Peter Schachte]

On Tue, Jan 04, 2000 at 01:55:25AM -0800, Ralph Becket wrote:
> > From: Peter Schachte [mailto:schachte at cs.mu.OZ.AU]
> > 
> > The amount of inconvenience of this approach will be directly
> > proportional to the number of default methods one would like and
> > inversely proportional to the number of non-default methods.  If there
> > are 10 default methods and 100 non-default ones, this doesn't look too
> > bad.  If there are 10 default methods and 1 non-default, it looks
> > terrible.
> 
> I don't agree: read_chars is something that I may very well want to
> override in an implementation.  I don't really have a problem with
> explicitly hooking up to default methods as that's often very helpful 
> when debugging or reading code.

But then the one line of real information in your declaration gets
lost among the 10 lines of "just do the usual thing" declarations.  I
don't find that convenient.  The point of abstraction is to allow you
to succinctly specify common configurations of something.

> > I suspect I'd tend to want a lot of default methods, as they would
> > allow both simplicity and flexibility in instance definitions, but
> > until I use type classes a bit, I don't really know.
> 
> I think you've hit the nail on the head here.  I can see lists becoming
> instances of a generalised sequence typeclass and most of the list module
> being ripped out into a module dealing with sequences in general.  The
> question is which operations are properly part of the typeclass and which
> are more generally useful?

Not so much "more generally useful" as "can't really be done any more
efficiently for any kind of sequence I can imagine, so might as well
be an ordinary predicate/function."

Hmmm.  As I think about it, this is one disadvantage of type classes
relative to orthodox object oriented programming: with type classes
you must make this decision before you know what instances you may one
day think up, whereas with object oriented programming, (most)
everything is a method, and can be overridden.  For example, the
obvious methods for a sequence are first and rest.  Then it's easy to
define nth by calling rest repeatedly, so at first thought one would
not want to make nth a method.  But for arrays-as-sequences, nth can
be implemented much more efficiently, so really nth should be a method
after all, and should have the obvious default.

This is where default methods are important:  they allow you to add new
methods to type classes without forcing every instance declaration
(which may be in user code) to change, as long as the new methods have
defaults.  It may even be possible to change an existing ordinary
library predicate into a method without changing code that uses it,
provided the existing code doesn't explicitly module qualify calls to
it (would this be possible, DJ?).  Without defaults, it will be
difficult to grow a type class library organically; it'll have to be
all planned out ahead, or much code that uses the library will be in
constant flux.

How do other languages with type class systems handle this problem?

-- 
Peter Schachte                     The use of COBOL cripples the mind; its
mailto:schachte at cs.mu.OZ.AU        teaching should, therefore, be regarded
http://www.cs.mu.oz.au/~schachte/  as a criminal offense.
PGP: finger schachte at 128.250.37.3      -- E. W. Dijkstra 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------