[Haskell-cafe] clonetype

Harendra Kumar harendra.kumar at gmail.com
Wed Sep 26 14:49:50 UTC 2018

On Wed, 26 Sep 2018 at 18:11, Wolfgang Jeltsch <wolfgang-it at jeltsch.info>

> Am Dienstag, den 25.09.2018, 02:05 +0530 schrieb Harendra Kumar:
> 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 *newtype*s 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.
> I think that the time it takes to come up with and write down such
> explicit lists is usually small compared to the time it takes to do all the
> other development. And once you have made the instantiation lists explicit,
> you will probably save time in the future, because bugs will detected
> automatically more often. The latter point is something that is often
> overlooked: people are under time pressure and strive for quick solutions
> but spend more time in the long run this way.

Two quick thoughts:

1) Nobody has pointed out what kind of bugs (with specific examples) will
arise if we have something like clonetype. Are those bugs more dangerous or
will consume more time compared to what we are trying to avoid in the first
place? I am just trying to learn more about it, not claiming that this is

2) It is a real unsolvable problem that people take shortcuts when
available, people will be people; this is also one of the reasons why
Haskell is not so successful, other languages are easy in the short run. If
we accept that this a fact of life, we have two options in general, (1)
provide a safer shorter route so that we automatically choose that one (2)
close the unsafe shorter route to force ourselves to choose the safe one. I
was trying to explore if there is a solution on the lines of the first
option. The second option means that we should not allow two arguments of
the same type in a function, forcing them to always make a newtype, perhaps
a much more draconian solution and not worth the pain.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180926/dd8fc7f9/attachment.html>

More information about the Haskell-Cafe mailing list