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" <jeffbrown.the@gmail.com> 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.