[Haskell-cafe] Type synonyms vs standard types

[Olex P]

This idea with new level of abstraction is good but in some cases it can
make things overcomplicated / less efficient. Does that mean "leave simple
built-in types as is"?
But probably that's all is the matter of habit and style.

Thanks guys


On Tue, Sep 29, 2009 at 8:58 PM, Luke Palmer <lrpalmer at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090929/b6d8bd1f/attachment.html