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 <ber...@ukr.net> 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 > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
