[Haskell-cafe] Type synonyms considered harmful?

Jeremy Shaw jeremy at n-heptane.com
Sun Jan 18 20:21:08 UTC 2015


In the land of Haskell Web Development, I tend to use newtypes instead of
types. In works well in that domain because we often use the types opaquely
anyway. For example, I might have a bunch of values like UserId, PageId,
etc, which are really just an Int(eger) underneath. Preventing them from
being mixed up is good. Also, I am not doing any calculations on them --
just storing, retrieving, and passing them around. Additionally, I am not
usually creating the values directly in my code. That is, I don't have a
bunch of code like, getUser (UserId 4). It is more like, do uid <-
getUserId ; user <- getUser uid. So newtypes are great in this domain.

Outside of webdev, it is tempting to use type aliases for functions that
have a lot of types where the meaning is not clear:

foo :: Int -> Int -> Double -> Double -> Double -> IO ()

using type alias provides a way to give them meaning:

foo :: X -> Y -> Red -> Blue -> Green -> IO ()

but, that is confusing because it hides the underlying types. It also
duplicates information that is available in the function declaration.

foo :: Int -> Int -> Double -> Double -> Double -> IO ()
foo x y r g b = ...

Now we see types and description names. Except haddock does not include a
way to show the names of the arguments in the docs.

Obviously, we need dependent types:

foo : (x : Int) -> (y : Int) -> (red : Double) -> (blue : Double) -> (green
: Double) -> IO ()

And that will solve everything! What could possibly go wrong!

- jeremy

On Sat, Jan 17, 2015 at 1:06 PM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150118/09941e66/attachment.html>


More information about the Haskell-Cafe mailing list