Another useful extension here could be "friend modules" and "friend packages," similar to friend declarations in C++. Then a restricted set of modules or packages could see inside a package to extend it, even as the package is closed to the rest of the world. Alex On Sat, Jun 19, 2010 at 1:29 PM, Roman Beslik wrote:

Hi, Christian. Here is my humble and somewhat vague thoughts. I think that export list is reasonable for commonly used and stable (ancient) library. Export list is a contract between library's author and user. Though current Haskell rules force author to have one and only one contract with all the people in the world. E.g. in law there is no such restriction. Assuming that (using/not using) an unstable function in the library is responsibility of library's user (not author), there may be: - declaration "import hidden" for importing everything; - compiler option for banning "import hidden"; - several export lists (in separate files) for different type of users. On 19.06.10 21:38, Christian Höner zu Siederdissen wrote:

...

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. … 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?

-- Best regards,  Roman Beslik.

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

On Sat, Jun 19, 2010 at 07:23:50PM -0700, Evan Laforge wrote:

On Sat, Jun 19, 2010 at 6:00 PM, Felipe Lessa wrote:

...

On Sat, Jun 19, 2010 at 08:38:52PM +0200, Christian Höner zu Siederdissen wrote:

...

But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)).

I think this is another problem.  Sure, without export lists you *currently* can't hide those constructors.  However, languages like Java don't have export lists as well.  Imagine if we could write this in Haskell:

private data Foo a = Foo a (Foo (Either a a))

But that's just a syntactical difference. I suspect whether you prefer to put visibility directly on the definition or collect it all in one place depends on personal taste and what you're used to.

That's my point. Hiding a constructor is orthogonal to using export lists. Cheers, -- Felipe.