[Haskell-beginners] Replace instances of module

[David McBride]

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.

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.

data MyType = ... -- old type

newtype MyType_v2 = MyType_v2 MyType
-- data MyType_v2 = ... -- alternatively, define same structure, if it
didn't change.

instance JSON MyType_v2 = ... - slightly different json instance.

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.

You could also do it in the reverse, with a _v1 type, but old clients will
have to be updated.

As an addendum, you might future proof your API a little by having a
phantom type variable.

data V1
data V2
data MyType tag = ... -- old type

v1_func :: MyType V1
v1_func = undefined
v2_func :: MyType V2
v2_func = undefined

At the cost of a slightly more complicated API for your users.  But that
won't protect you if MyType itself changes.

On Mon, Jan 8, 2018 at 9:31 AM, Baa <aquagnu at gmail.com> wrote:

> Hello, Francesco.
>
> Actually the whole problem is that I have library (consisting of
> several modules: types, API calls, JSON instances, etc) to work with
> some REST service. Now I have 2 nodes with this service: version 1 and
> version 2, so API is little bit changed in version 2 (mostly in JSON
> instances, but types seems to be the same, API calls will be the same
> too).
>
> So, clients must work with both services: of version 1 and version 2.
> And I can create new library, but this will be big copy-paste, because
> mostly code (except JSON instances) will be the same. Different will be
> returned value in some API calls, maybe - I'm not sure. Nothing else.
>
> So, if I'll create new version of library: how they will live together
> with the same names, etc, only different version?! And common
> code-base will lead to complex bug-fixing and test modification. If
> I'll name new library like "oldlibv2" - problem with bug fixing and
> testing is still here.
>
> My idea was to "patch" in some way existing library by import some
> modules into new modules and reimplement some instances only. May be
> the same with API calls, I'm not sure here.
>
> I know that it's easy in F#, ML and Python, for example. Are backpacks
> something like ML modules? I see that they are not supported by stack.
> What does it mean? "import" will not work?
>
> Actually I don;t know - is some better way to solve such problem? I'm
> sure many of us communicate with some RESTfull APIs. Then APIs change.
> And your apps should work with old and new APIs (services), so you
> should clone existing library to support both versions (together, at
> the same time, in one client application!).
>
> ===
> Best regards, Paul
>
> > Hello Paul,
> >
> > On Mon, Jan 08, 2018 at 03:20:20PM +0200, Pv wrote:
> > > Hello, all.
> > >
> > > Is it possible to import all types except some of instances and to
> > > re-defined hiding instances, so resulting (new) module will be the
> > > same types, mostly the same instances, but some of instances will be
> > > replaced?
> >
> > Nope, instances are automatically imported! You can create newtypes
> > and have them instances of what you need or check the newfangled
> > `backpack` [1]!
> >
> > [1] https://ghc.haskell.org/trac/ghc/wiki/Backpack
> > _______________________________________________
> > Beginners mailing list
> > Beginners at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20180108/373a890f/attachment.html>