Do note that my proposed "r" solution does not solve the problem of scanl vs scanr. (!!!) Another reason to dislike it. Would you also call input types 'i', or maybe 'a' because they are
arguments, or 'p' because they are parameters?
I wouldn't. The allure of using "r" is that when you see "r" *earlier* in the type signature, then you know it must be the same as the "result". Using a mnemonic for function inputs doesn't carry the same benefit, although for something like Conduit "i"nput and "o"utput make sense. If at all, the letter 'z' would be more logical I'd be happy with "z" just as much as "r". "z" is nice because it obviously doesn't stand for anything, but it still holds mnemonic value for the concept of "the end". Let the "z versus r" bikeshedding wars begin! [z] works for functions with more parameters Is that really a concern? It takes 18 distinct parameters to get from a to r. -1 for using anything longer than "acc". I'd be ok with just "acc" as is used currently in docs for mapAccum*, though I'd prefer a single-letter variable. -- Dan Burton