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
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