[Haskell-cafe] Type synonyms considered harmful?

[Sumit Sahrawat, Maths & Computing, IIT (BHU)]

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 at 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 at 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150118/8ae50210/attachment.html>