I've tried using longer type variable names in some of my personal projects and found a surprising problem: it became harder to tell types from value-level expressions at a glance. In a lot of cases, I actually found the resulting code harder to read on net. There are still times when I use longer type variable names in my code, but I now think that single-letter names are actually a good default—I need a good reason to deviate from them. I think this happens because type signatures tend to be short, relatively self-contained and often repeated. I want to be able to parse type signatures quickly, at a glance. Longer type variables might be clearer the first time you encounter a library, but they often become a pain once you're familiar with it. (I follow the same reasoning for using short names for function arguments and local definitions that are used in a restricted scope.) :browse through Parsec and consider how many ParsecTs you see, often with multiple in a single type signature. With this much repetition, variables consistently named by connection become useful. Sure, you might need to learn the convention, but the up-front work pays off for itself in any non-trivial use of the library. Of course, there should also be clear documentation on the type definition defining what the variables mean. Gabriel Gonzalez's Pipes library is a perfect example of how this can be done. On Aug 10, 2017 6:32 PM, "Jeffrey Brown" wrote:

Haskellers tend to use uninformative single-letter type variables. A case in point:

Megaparsec> :i ParsecT

type role ParsecT nominal nominal representational representational newtype ParsecT e s (m :: * -> *) a ...

I've gotten used to the conventions that "a" stands for anything and "m" stands for monad -- but without digging into the code it wasn't initially obvious to me whether "s" stood for stream or state.

Single-letter type variables don't seem to always be the standard, though:

Megaparsec> :i between between :: Applicative m => m open -> m close -> m a -> m a -- Defined in ‘Control.Applicative.Combinators’

My questions are: (1) Are the brevity gains worth the confusion costs? (2) If I'm looking at a new library for the first time and trying to figure out what a type variable stands for, is there a canonical way to do it? Flailing through documentation at random? Unifying types by hand?

-- Jeff Brown | Jeffrey Benjamin Brown Website https://msu.edu/~brown202/ | Facebook https://www.facebook.com/mejeff.younotjeff | LinkedIn https://www.linkedin.com/in/jeffreybenjaminbrown(spammy, so I often miss messages here) | Github https://github.com/jeffreybenjaminbrown

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

(2) If I'm looking at a new library for the first time and trying to figure out what a type variable stands for, is there a canonical way to do it?

Type variables inherently don't have any meaning – the meaning only comes from how they are used and how they are constrained. Therefore, you need to look for clues based on (1) the constraints on the type variable, if any, and (2) the types that use the variable. For parsec it's pretty easy because the type variables are often constrained by Stream and used by the ParsecT type. The documentation of parsec is really detailed: both Stream and ParsecT tell you precisely what 's' and 'm' are, and the library is very consistent with this convention. IMO, good documentation should always explain every type variable in every `data` or `newtype` declaration. I would say part of the reason Haskell uses single-letter variables a lot is that a lot of the code are very general and the authors did not want to impose their domain-specific interpretation on it. In some situations (e.g. application code, domain-specific libraries), writing out the variables in full can be meaningful, but in library code this is rare.