Re: [Haskell-cafe] Type synonyms considered harmful?

Projects written in an imperative style are the ones where type synonyms can really help. For example, some gtk functions have horrible type declarations, like adjustmentNew :: Double -> Double -> Double -> Double -> Double -> Double -> IO Adjustment Gtk was designed for an imperative setting, and as such should provide type synonyms to make users more comfortable. In a purely functional style type synonyms are not as necessary. Most functions are self-descriptive, e.g. a function operating on age would make it obvious that it's operating on age, like, incrementAge :: Int -> Int You can argue that this declaration is more informative, as it doesn't hide the details of 'Age' but yet doesn't confuse the reader. As for help provided by the editor, I use emacs-haskell-mode, and it provides interactions with an inferior ghc process. It allows you to query the type and then see the result at the bottom of the window. On 18 January 2015 at 01:37, Mathieu Boespflug wrote:

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

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards Sumit Sahrawat