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
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe