<div dir="ltr">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.<div><br></div><div>Outside of webdev, it is tempting to use type aliases for functions that have a lot of types where the meaning is not clear:</div><div><br></div><div>foo :: Int -> Int -> Double -> Double -> Double -> IO ()</div><div><br></div><div>using type alias provides a way to give them meaning:</div><div><br></div><div>foo :: X -> Y -> Red -> Blue -> Green -> IO ()</div><div><br></div><div>but, that is confusing because it hides the underlying types. It also duplicates information that is available in the function declaration.</div><div><br></div><div>foo :: Int -> Int -> Double -> Double -> Double -> IO ()</div><div>foo x y r g b = ...</div><div><br></div><div>Now we see types and description names. Except haddock does not include a way to show the names of the arguments in the docs.</div><div><br></div><div>Obviously, we need dependent types:</div><div><br></div><div>foo : (x : Int) -> (y : Int) -> (red : Double) -> (blue : Double) -> (green : Double) -> IO ()</div><div><br></div><div>And that will solve everything! What could possibly go wrong!</div><div><br></div><div>- jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 17, 2015 at 1:06 PM, Julian Ospald <span dir="ltr"><<a href="mailto:hasufell@posteo.de" target="_blank">hasufell@posteo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I've recently had a discussion about type synonyms and when to use them<br>
in haskell.<br>
<br>
On the one hand, they make reading type signatures easier and tell you<br>
what is meant, not just what is inside. On the other hand they also sort<br>
of hide what is inside, although you will probably need to know exactly<br>
that when using them. This might make reading code for new collaborators<br>
more difficult if they have to memorize all type synonyms first.<br>
<br>
So there are basically a few questions:<br>
* What do you think is a good policy for when and how to use them? Or<br>
would you say just not use them at all and put equivalent information in<br>
parameter documentation?<br>
* What are the upsides, downsides, pitfalls and also alternatives? (for<br>
completeness, also since<br>
<a href="https://www.haskell.org/haskellwiki/Type_synonym" target="_blank">https://www.haskell.org/haskellwiki/Type_synonym</a> is a bit sparse)<br>
* Can we do something to improve the downsides? Or is there already<br>
something? (e.g. editor/IDE that can tell me the underlying type, error<br>
messages etc.)<br>
<br>
<br>
--<br>
Regards,<br>
Julian Ospald<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>