[Haskell-cafe] clonetype

[Levent Erkok]

If you're OK with a little template Haskell and standalone-deriving, then
you can use the trick discussed here:


https://stackoverflow.com/questions/45113205/is-there-a-way-to-shorten-this-deriving-clause

Here's a concrete implementation in my case:

  https://github.com/LeventErkok/sbv/blob/master/Data/SBV.hs#L407-L420

And a use-case:


https://github.com/LeventErkok/sbv/blob/master/Documentation/SBV/Examples/Queries/Enums.hs#L23-L27

Without that trick, the line would've looked like almost like what you had
to write with `Count`.

I've used this trick for quite some time now, and it's both cheap and quite
effective. I agree that a directly supported `deriving` syntax would be
nicer, but TH fits the bill well here.

-Levent.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180924/0f7d3285/attachment.html>