<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>The reason you don't get to override instances within a package is that haskell accounts for the fact that a library user could import both old and new, ending up with two conflicting instances for the same type.<br><br></div>If one of the types now needs two different JSON instances, one way to do that is to wrap it in a newtype that has a different JSON instance.<br><br></div><div>data MyType = ... -- old type<br><br></div>newtype MyType_v2 = MyType_v2 MyType<br></div><div>-- data MyType_v2 = ... -- alternatively, define same structure, if it didn't change.<br><br></div>instance JSON MyType_v2 = ... - slightly different json instance.<br><br></div>Then you can have a module that has a function that returns MyType_v2 from its functions instead and exports a JSON instance for it.  Users can import either or both and will have access to both instances and both types.<br><br></div>You could also do it in the reverse, with a _v1 type, but old clients will have to be updated.<br><br></div>As an addendum, you might future proof your API a little by having a phantom type variable.<br><br></div><div>data V1<br></div><div>data V2<br></div>data MyType tag = ... -- old type<br><br></div>v1_func :: MyType V1<br></div><div>v1_func = undefined<br></div>v2_func :: MyType V2<br>v2_func = undefined<br><br></div>At the cost of a slightly more complicated API for your users.  But that won't protect you if MyType itself changes.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 9:31 AM, Baa <span dir="ltr"><<a href="mailto:aquagnu@gmail.com" target="_blank">aquagnu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello, Francesco.<br>
<br>
Actually the whole problem is that I have library (consisting of<br>
several modules: types, API calls, JSON instances, etc) to work with<br>
some REST service. Now I have 2 nodes with this service: version 1 and<br>
version 2, so API is little bit changed in version 2 (mostly in JSON<br>
instances, but types seems to be the same, API calls will be the same<br>
too).<br>
<br>
So, clients must work with both services: of version 1 and version 2.<br>
And I can create new library, but this will be big copy-paste, because<br>
mostly code (except JSON instances) will be the same. Different will be<br>
returned value in some API calls, maybe - I'm not sure. Nothing else.<br>
<br>
So, if I'll create new version of library: how they will live together<br>
with the same names, etc, only different version?! And common<br>
code-base will lead to complex bug-fixing and test modification. If<br>
I'll name new library like "oldlibv2" - problem with bug fixing and<br>
testing is still here.<br>
<br>
My idea was to "patch" in some way existing library by import some<br>
modules into new modules and reimplement some instances only. May be<br>
the same with API calls, I'm not sure here.<br>
<br>
I know that it's easy in F#, ML and Python, for example. Are backpacks<br>
something like ML modules? I see that they are not supported by stack.<br>
What does it mean? "import" will not work?<br>
<br>
Actually I don;t know - is some better way to solve such problem? I'm<br>
sure many of us communicate with some RESTfull APIs. Then APIs change.<br>
And your apps should work with old and new APIs (services), so you<br>
should clone existing library to support both versions (together, at<br>
the same time, in one client application!).<br>
<br>
===<br>
Best regards, Paul<br>
<div class="HOEnZb"><div class="h5"><br>
> Hello Paul,<br>
><br>
> On Mon, Jan 08, 2018 at 03:20:20PM +0200, Pv wrote:<br>
> > Hello, all.<br>
> ><br>
> > Is it possible to import all types except some of instances and to<br>
> > re-defined hiding instances, so resulting (new) module will be the<br>
> > same types, mostly the same instances, but some of instances will be<br>
> > replaced?<br>
><br>
> Nope, instances are automatically imported! You can create newtypes<br>
> and have them instances of what you need or check the newfangled<br>
> `backpack` [1]!<br>
><br>
> [1] <a href="https://ghc.haskell.org/trac/ghc/wiki/Backpack" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/wiki/Backpack</a><br>
> ______________________________<wbr>_________________<br>
> Beginners mailing list<br>
> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/beginners</a><br>
<br>
______________________________<wbr>_________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/beginners</a><br>
</div></div></blockquote></div><br></div>