Thanks everybody for your thoughts. Based on what I've read this is what I will do: - fork a 'foreign' library, if I need to extend it substantially - export everything explicitly - or set namespaces like this: - Library (with the more stable interface) - Library.Internal (which exports everything) Because of the rather good versioning system of Cabal (like library=x.y.z) this seems to be the most practical solution for me. Though it still would be nice if I could inject functions into other peoples' namespaces -- so to speak ;-) Gruss, Christian * Christian Höner zu Siederdissen [19.06.2010 20:39]:

Hi everybody,

I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one:

- efficiencey (inlining in the module) - encapsulation

in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)).

So, should I really fork a library just to be able to add a function?

Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users