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 <mboes@tweag.net> 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 <hasufell@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@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