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 <lrpal...@gmail.com> wrote: > On Tue, Sep 29, 2009 at 11:40 AM, Olex P <hoknam...@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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe