Proposal: Partitionable goes somewhere + containers instances

[Ryan Newton]

Hi all,

Thanks for more feedback.

I tend to not be afraid of the ".Internal" module that exposes stuff that
changes, with appropriate caveats.  But it also seems like relatively
little effort to have a cleaner public "splitTree" interface in this case,
hopefully without extra overhead.

I propose to test simple use cases of a tuple and list version of splitTree
and check out the deforestation properties.

Milan, I know the three-tuple version looks weird.  But since it's OK for
some of those three chunks to be empty I think most future implementations
would have an easy way to maintain compatibility, wouldn't they?

UNLESS, that is,y our new changes involve trees that would expose
*more*than three-way-splits at a time (4-way, 5-way, etc).  Do they?

Cheers,
  -Ryan



On Mon, Oct 7, 2013 at 12:51 PM, Edward Kmett <ekmett at gmail.com> wrote:

> While it is PVP compliant, it would also tie the hands of the developers
> enough that I don't see many developers wanting to adopt it. Working across
> multiple packages means very painful changes to your build process if you
> don't use cabal install for everything. It is even rather painful if you do
> use cabal install for everything.
>
> A slightly more palatable PVP compliant version which burns through
> version numbers much faster is to separate the two digits of the major
> version and use one for .Internal changes and one for changes to the
> majority of the public API. Then users who only use the public API can
> depend on the first digit. However, this has awkward aesthetics as your
> version numbers start skyrocketing.
>
> I'm not a fan of either approach.
>
> -Edward
>
>
> On Mon, Oct 7, 2013 at 10:35 AM, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Mon, 7 Oct 2013, Edward Kmett wrote:
>>
>>  A rule of thumb that has served me well w.r.t exposing internal modules
>>> is to expose a Data.Foo.Internal but
>>> make it clear it is a very fragile interface.
>>> Even by going to far as to say this module does not follow the PVP and
>>> that they should expect breaking
>>> changes to come fast and often. Users should only safely depend on it
>>> with minor-version specific bounds
>>> then. This ameliorates the concerns about how it ties your hands as an
>>> implementor.
>>>
>>
>> A PVP compliant solution would be to divide 'containers' into
>> 'containers-internal' and 'containers'. The new package
>> 'containers-internal' exposes internal data structures, but increases
>> version numbers at a higher rate than 'containers'. The package
>> 'containers' would only expose the public API and thus a more stable
>> interface.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131007/dbd4df41/attachment.html>