Modules and their explicit export lists (are an annoyance)

Alexander Dunlap alexander.dunlap at gmail.com
Sun Jun 20 13:33:25 EDT 2010


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 <beroal at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


More information about the Glasgow-haskell-users mailing list