[Haskell-cafe] clonetype

[Evan Laforge]

For some reason I thought ConstraintKinds would let you do:

type UsualStuff a = (Eq a, Read a, ...)
newtype .. deriving (UsualStuff)

No such luck apparently!
On Mon, Sep 24, 2018 at 1:36 PM Harendra Kumar <harendra.kumar at gmail.com> wrote:
>
>
>
> 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
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.