[Haskell-cafe] Type synonyms considered harmful?
qdunkan at gmail.com
Mon Jan 19 11:15:03 UTC 2015
I think they have their place. I use them when it's too much bother
to unwrap a newtype but still nice to have some documentation,
especially if it shows up in many places but I only want to document
in one place. Or if I think a type error is unlikely, or not a big
deal, compared to the wrap/unwrap hassle. For documentation it's also
nice to have a name to use in haddock. Also I tend to use them when
the scope is small. I agree that if the scope is wide, or if it's a
library, then they can be not worth it. E.g. I've decided to not use
Data.Graph's 'type Forest a = [Tree a]'.
It's a convenience vs. correctness trade-off, and it's useful to have
something covering the convenience end. Perhaps you shouldn't put
them in library APIs though.
On Sun, Jan 18, 2015 at 3:06 AM, Julian Ospald <hasufell at posteo.de> wrote:
> 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.)
> Julian Ospald
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe