[m-dev.] for review: stream I/O

[Michael Day]

> My concern is that for some applications it may be more efficient to
> implement method foo for type t at the level of t rather than as a
> wrapper and that this may be critical to performance.

Hmm this is a more general issue that will affect all the interfaces
defined in the standard library I suspect - didn't the paper on Edison
bring this up as well? I'm sure there are many algorithms on containers
(like map?) which you can implement in a general way that works for all
containers but fails to take advantage of the properties of a particular
container that would have allowed a more efficient implementation.

Would default type class methods as you have suggested solve this? It
seems that protracted deliberation is going to be needed when designing
this interfaces (as seems to be happening :) as it is not possible to add
*every* possible method that may someday be implemented efficiently by
some obscure instance.

Michael

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