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
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe