[Haskell-cafe] Type synonyms considered harmful?

[Mathieu Boespflug]

I tend to reserve type synonyms exclusively for *abbreviating* types,
for example when they end up being long and unwieldy. Since this is
seldom necessary, I seldom use type synonyms. Others (ab?)use type
synonyms to convey semantic information, e.g.

type Age = Int

However, if the need for naming things separately at the type level
really is pressing, then one could argue that for that you would be
better served introducing a newtype anyways.

IOW, my rule of thumb is: type synonyms only as abbreviations,
newtypes for semantically distinct entities, neither when the overhead
of a newtype wouldn't pay its own way in terms of either static
checking or clarity.

Best,

Mathieu

On 17 January 2015 at 20:06, Julian Ospald <hasufell at posteo.de> wrote:
> Hi,
>
> I've recently had a discussion about type synonyms and when to use them
> in haskell.
>
> On the one hand, they make reading type signatures easier and tell you
> what is meant, not just what is inside. On the other hand they also sort
> of hide what is inside, although you will probably need to know exactly
> that when using them. This might make reading code for new collaborators
> more difficult if they have to memorize all type synonyms first.
>
> So there are basically a few questions:
> * What do you think is a good policy for when and how to use them? Or
> would you say just not use them at all and put equivalent information in
> parameter documentation?
> * What are the upsides, downsides, pitfalls and also alternatives? (for
> completeness, also since
> https://www.haskell.org/haskellwiki/Type_synonym is a bit sparse)
> * Can we do something to improve the downsides? Or is there already
> something? (e.g. editor/IDE that can tell me the underlying type, error
> messages etc.)
>
>
> --
> Regards,
> Julian Ospald
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe