[Haskell-cafe] Type synonyms vs standard types

[Luke Palmer]

On Tue, Sep 29, 2009 at 11:40 AM, Olex P <hoknamahn at gmail.com> wrote:
> Hi everyone,
>
> Dumb question about declaring a function and type synonyms.
> There are to different declarations of the same function:
>
> attrNames :: String -> AttrDict -> [String]
>
> attrNames :: AttrClass -> AttrDict -> AttrNames
>
> First gives you the idea about exact types it expects (except AttrDict for
> which user has to take a look into the docs or sources) while the second one
> gives you the idea about meaning of parameters.
> Both reasons make sense. The question is when which one should be used? I'm
> using type synonyms everywhere and possibly without too much reasons...
> Maybe I should stop doing it? :)

I get the impression that it is still largely a matter of style, and
the community hasn't reached a consensus.

Personally, I don't usually use type synonyms for this purpose.  The
function name and type are usually enough.  Eg in attrNames above it
should be clear what's going on: you are taking one AttrDict and one
String, so the String is probably a key into the dictionary.  The
return is a list of Strings, and your function is called "attrNames",
so it's probably a list of attr names.

In the cases when it is not as obvious, I usually increase the level
of abstraction (typechecked documentation) instead of introducing
synonyms (un-typechecked documentation).  Take for example the
function which checks whether a point is inside a bounding box:

insideBoundingBox :: Point -> Point -> Point -> Bool

I could use synonyms to rename those arguments:

insideBoundingBox :: LowerLeftPoint -> UpperRightPoint -> Point -> Bool

But I would prefer to introduce a new abstraction:

data BoundingBox = BoundingBox { lowerLeft :: Point, upperRight :: Point }
insideBoundingBox :: BoundingBox -> Point -> Bool

And now the roles of the arguments are clear again.

Luke