<div dir="ltr">yup! <div><br></div><div>its accepted convention by the community that *.Internal Modules are not subject to ANY API stability guarantees (kinda like the GHC apis :) )</div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Sun, Apr 13, 2014 at 8:25 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 14 April 2014 10:22, David Thomas <<a href="mailto:davidleothomas@gmail.com">davidleothomas@gmail.com</a>> wrote:<br>
> A concern, to be sure. On the flip side, it might be better to know what<br>
> you are actually exposing (also meaning fewer things would constitute a<br>
> breaking change).<br>
<br>
</div>There is the convention that "if it's in a .Internal module, then<br>
you're on your own: this module doesn't contribute towards breaking<br>
changes in the API".<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Apr 13, 2014 5:00 PM, "John Lato" <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br>
>><br>
>> It's possible to restrict LogTree.Internal to be visible only within the<br>
>> package (see cabal's other-modules field), but please don't do so. You will<br>
>> inevitably fail at providing every necessary function or accommodating all<br>
>> reasonable uses of your library. Then some user will either write their<br>
>> own, use something else or, if you're lucky, fork your library and send you<br>
>> a merge request. It will happen (unless you have no other users).<br>
>><br>
>> As a recent example, I was using a library that had an internal data<br>
>> structure, 'A' (completely unexposed) as part of an exposed data structure<br>
>> 'B'. Both had 'deriving Generic' clauses. However, the Generic instance of<br>
>> 'B' was mostly useless because if you wanted to use the Generic instance to<br>
>> declare e.g. 'instance Binary B', it's also necessary to create a Binary<br>
>> instance for 'A'. Which was impossible for users, because 'A' was<br>
>> completely unexposed. When I pointed this out, the library's author<br>
>> graciously accepted a patch to expose the type constructor 'A' (I'm not<br>
>> entirely happy with this solution either, but for now we can't think of<br>
>> anything better).<br>
>><br>
>> You could take this as an implementation flaw of Generic as it's currently<br>
>> implemented (which it possibly is), however I would hope you also take it as<br>
>> a demonstration of how data abstraction can interact with many different<br>
>> language features in often-subtle ways. I think erring on the side of<br>
>> allowing users maximum freedom is the best choice for now (preferably<br>
>> stashed in modules/functions with names like 'internal' or 'unsafe').<br>
>><br>
>> John<br>
>><br>
>><br>
>> On Sun, Apr 13, 2014 at 7:02 AM, Luke Clifton <<a href="mailto:ltclifton@gmail.com">ltclifton@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi David,<br>
>>><br>
>>> I think you can do something like providing a LogTree.Internal module<br>
>>> which you use internally and which exports everything you need, and making<br>
>>> your LogTree module which re-exports only the safe subset which "unknown"<br>
>>> code would then import. I don't think there is a way of stopping anyone from<br>
>>> importing your LogTree.Internal module though.<br>
>>><br>
>>><br>
>>><br>
>>> On Sun, Apr 13, 2014 at 9:42 PM, David Banas <<a href="mailto:capn.freako@gmail.com">capn.freako@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi all,<br>
>>>><br>
>>>> I’ve defined a typeclass, LogTree, and would like to put each instance<br>
>>>> definition in its own source file, in order that LogTree.hs not grow to a<br>
>>>> ridiculous length.<br>
>>>> I’m attempting to use data abstraction, in order to future-proof the<br>
>>>> user interface to this class.<br>
>>>> So, for instance, I don’t make all of the data constructors defined in<br>
>>>> LogTree accessible, via the module export list, but rather force the user to<br>
>>>> use certain “helper” functions, instead.<br>
>>>> However, the individual instance definitions do need access to these<br>
>>>> data constructors, but they’re in a different source file.<br>
>>>><br>
>>>> Is this possible? That is, is it possible to provide different export<br>
>>>> lists to “friendly” vs. “unknown” client code?<br>
>>>><br>
>>>> Thanks,<br>
>>>> -db<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Haskell-Cafe mailing list<br>
>>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Haskell-Cafe mailing list<br>
>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>