[Haskell-cafe] clonetype

[Harendra Kumar]

On Tue, 25 Sep 2018 at 01:12, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> On 24.09.2018 17:06, Harendra Kumar wrote:
> >
> >
> > On Mon, 24 Sep 2018 at 18:17, Oleg Grenrus <oleg.grenrus at iki.fi
> > <mailto:oleg.grenrus at iki.fi>> wrote:
> >
> >     The problem is that "All instances" is hard to pin point. We have
> >     open world assumption, so instances can be added later (in the
> >     dependency tree). Should they be cloned too? And even of you
> >     restrict to "instances visible at clonetype definition", that's
> >     IMHO not a good idea either, as it's implicit and volatile set
> >     (editing imports changes may change the set).
> >
> >
> > A clone type says "both the types are exactly the same in all
> > semantics except that they cannot be used interchangeably", it is just
> > like "type" except that the types are treated as being different. The
> > way visible instances change for the original type by editing imports,
> > the same way they change for the clone type as well, I do not see a
> > problem there. However, the two types may diverge if we define more
> > instances for any of them after cloning and that may potentially be a
> > source of confusion?
>
> If you want that, then the GeneralizedNewtypeDeriving is the solution.
> It's not so convinient, as you have to list the instances you need, but
> on the flip side of the coin is the "explicitness" of the deriving
> clause. GHC will barf if you forget an import for an instance you want,
> or if you have unused import. Often redundancy is your friend. Type
> annotations very often aren't necessary, but it's good practice to write
> them (e.g. for top-level definitions). So I'd say that not having
> `clonetype` is a feature.
>
>
That's where I started. I already use a newtype with GND for this, and it
looks like this:

newtype Count = Count Int64
    deriving ( Eq
             , Read
             , Show
             , Enum
             , Bounded
             , Num
             , Real
             , Integral
             , Ord
             )

The problem is that most programmers are lazy or hard pressed for time and
having to write a newtype with a big list of instances actually discourages
the use of newtypes freely for this case, they may just make it a habit to
let it go. We can't just deny this and say that programmers must be
disciplined. They will often try taking the path of least effort. So in
practice I am not sure what is better, being explicit or encouraging the
use of distinct types and potentially avoiding bugs by doing so. What kind
of actual problems/bugs may arise by not being explicit in this particular
case?

-harendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180925/0100d37f/attachment.html>