<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">: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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Aug 10, 2017 6:32 PM, "Jeffrey Brown" <<a href="mailto:jeffbrown.the@gmail.com">jeffbrown.the@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Haskellers tend to use uninformative single-letter type variables. A case in point:</div><div><br></div><div>    Megaparsec> :i ParsecT                                                         </div><div>    type role ParsecT nominal nominal representational representational</div><div>    newtype ParsecT e s (m :: * -> *) a ...</div><div><br></div><div>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.</div><div><br></div><div>Single-letter type variables don't seem to always be the standard, though:</div><div>    </div><div>    Megaparsec> :i between</div><div>    between :: Applicative m => m open -> m close -> m a -> m a</div><div>            -- Defined in ‘Control.Applicative.<wbr>Combinators’</div><div><br></div><div>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?</div><div><br></div>-- <br><div class="m_7327085711275931677gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Jeff Brown | Jeffrey Benjamin Brown</div><div dir="ltr"><a href="https://msu.edu/~brown202/" style="font-size:12.8px" target="_blank">Website</a>   |   <a href="https://www.facebook.com/mejeff.younotjeff" style="font-size:12.8px" target="_blank">Facebook</a>   |   <a href="https://www.linkedin.com/in/jeffreybenjaminbrown" style="font-size:12.8px" target="_blank">LinkedIn</a><span style="font-size:12.8px">(spammy, so I often miss messages here)   </span><span style="font-size:12.8px">|</span><span style="font-size:12.8px">   </span><a href="https://github.com/jeffreybenjaminbrown" style="font-size:12.8px" target="_blank">Github</a><span style="font-size:12.8px">   </span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div></div>