Projects written in an imperative style are the ones where type synonyms can really help. For example, some gtk functions have horrible type declarations, like adjustmentNew :: Double -> Double -> Double -> Double -> Double -> Double -> IO Adjustment Gtk was designed for an imperative setting, and as such should provide type synonyms to make users more comfortable. In a purely functional style type synonyms are not as necessary. Most functions are self-descriptive, e.g. a function operating on age would make it obvious that it's operating on age, like, incrementAge :: Int -> Int You can argue that this declaration is more informative, as it doesn't hide the details of 'Age' but yet doesn't confuse the reader. As for help provided by the editor, I use emacs-haskell-mode, and it provides interactions with an inferior ghc process. It allows you to query the type and then see the result at the bottom of the window. On 18 January 2015 at 01:37, Mathieu Boespflug wrote:

I tend to reserve type synonyms exclusively for *abbreviating* types, for example when they end up being long and unwieldy. Since this is seldom necessary, I seldom use type synonyms. Others (ab?)use type synonyms to convey semantic information, e.g.

type Age = Int

However, if the need for naming things separately at the type level really is pressing, then one could argue that for that you would be better served introducing a newtype anyways.

IOW, my rule of thumb is: type synonyms only as abbreviations, newtypes for semantically distinct entities, neither when the overhead of a newtype wouldn't pay its own way in terms of either static checking or clarity.

Best,

Mathieu

On 17 January 2015 at 20:06, Julian Ospald 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards Sumit Sahrawat

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

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

How about a type-level the? =p type The label t = t foo :: The red Double -> The green Double -> The blue Double -> IO () Or with polykinds: foo :: The "Red" Double -> The "Green" Double -> The "Blue" Double -> IO ()

Now we're definitely getting somewhere! I'm not to thrilled about the use of string literals though. How about this? {-# LANGUAGE TypeOperators, DataKinds, RankNTypes #-} type (l ∷ t) = t foo :: forall red green blue. (red ∷ Double) -> (green ∷ Double) -> (blue ∷ Double) -> IO () We just need to patch hlint to make this the suggested style. - jeremy On Sun, Jan 18, 2015 at 7:05 PM, Niklas Haas wrote:

On Mon, 19 Jan 2015 01:12:58 +0100, Christopher Done wrote:

...

...

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

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

How about a type-level the? =p

type The label t = t

foo :: The red Double -> The green Double -> The blue Double -> IO ()

Or with polykinds:

foo :: The "Red" Double -> The "Green" Double -> The "Blue" Double -> IO ()

Clearly needs more TypeOperators.

type (l ∷ t) = t

foo :: ("red" ∷ Double) -> ("green" ∷ Double) -> ("blue" ∷ Double) -> IO () _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

That's pretty but a pain to type. On 21 January 2015 at 16:32, Niklas Haas wrote:

...

Now we're definitely getting somewhere! I'm not to thrilled about the use of string literals though. How about this?

{-# LANGUAGE TypeOperators, DataKinds, RankNTypes #-} type (l ∷ t) = t

foo :: forall red green blue. (red ∷ Double) -> (green ∷ Double) -> (blue ∷ Double) -> IO ()

We just need to patch hlint to make this the suggested style.

- jeremy

In fact, why even bother with the explicit forall? Default behavior is to universally quantify unused variable names, after all.

{-# LANGUAGE TypeOperators #-}

type (l ∷ t) = t

foo :: (red ∷ Double) -> (green ∷ Double) -> (blue ∷ Double) -> IO ()

At this point, I think this is a syntax form we can surely all agree upon. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Because that wouldn't show up in haddock or :t. On 22 January 2015 at 01:23, wrote:

Considering it doesnt give you any type safety, why not just write:

foo (red :: Double) (green :: Double) (blue :: Double) = undefined

Tom

El Jan 21, 2015, a las 10:32, Niklas Haas escribió:

...

...

Now we're definitely getting somewhere! I'm not to thrilled about the use of string literals though. How about this?

{-# LANGUAGE TypeOperators, DataKinds, RankNTypes #-} type (l ∷ t) = t

foo :: forall red green blue. (red ∷ Double) -> (green ∷ Double) -> (blue ∷ Double) -> IO ()

We just need to patch hlint to make this the suggested style.

- jeremy

In fact, why even bother with the explicit forall? Default behavior is to universally quantify unused variable names, after all.

{-# LANGUAGE TypeOperators #-}

type (l ∷ t) = t

foo :: (red ∷ Double) -> (green ∷ Double) -> (blue ∷ Double) -> IO ()

At this point, I think this is a syntax form we can surely all agree upon. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 19/01/2015 01:02, Christopher Done wrote:

I personally really dislike type synonyms, 9 times out of 10 I would prefer to just read a full type than the obscured synonym which hides useful structure from me.

i find type synonyms mostly useful during prototyping, i.e. when what I want is actually a newtype for safer interfaces but I don't want to bother with wrapping/unwrapping or figuring out how to derive instances; this is especially true for monad transformer stacks. later, after the code has settled a bit, it's straight forward, if tedious, to change the type to a newtype and fix the resulting type errors. sk

But in a public library, finding out that a type X is actually 'Either z' kind of blocks the way

It does. It's quite annoying to have to jump through several layers of indirections especially since (currently) Haddock-generated documentation requires you to click through the link to see what it's aliased to (a mouseover tooltip would be really nice to have!). I would rather just document each parameter using the `-- ^` syntax.

In general, use newtypes instead of type synonyms, and records instead of tuples. Also, ghc has its flaws when dealing with type synonyms, i.e., in error messages you find a type synoym needlessly expanded. Does anyone know a programming language that has type synonyms and always uses the type syn. in error messages when the user originally wrote it? I'd be eager to learn. Cheers, Andreas On 19.01.2015 12:15, Evan Laforge wrote:

I think they have their place. I use them when it's too much bother to unwrap a newtype but still nice to have some documentation, especially if it shows up in many places but I only want to document in one place. Or if I think a type error is unlikely, or not a big deal, compared to the wrap/unwrap hassle. For documentation it's also nice to have a name to use in haddock. Also I tend to use them when the scope is small. I agree that if the scope is wide, or if it's a library, then they can be not worth it. E.g. I've decided to not use Data.Graph's 'type Forest a = [Tree a]'.

It's a convenience vs. correctness trade-off, and it's useful to have something covering the convenience end. Perhaps you shouldn't put them in library APIs though.

On Sun, Jan 18, 2015 at 3:06 AM, Julian Ospald 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/