<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the accumulator should not be named 'r' because there are many result types in the List module that are not named 'r' and should not be, for instance because argument and result have the same type or are just Int or Bool.</blockquote>
<div><br></div><div>I agree that many result types in the List module should not be named 'r'. I therefore suggest that the convention be used only in cases like "foldr" where there are *two or more type variables*, and we can benefit from more clearly distinguishing one from the others. The current convention seems to be left-to-right a-thru-z, which as the foldr vs foldl issue illustrates, is suboptimal.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The distinguishing feature of a result type is that it is the last type in a chain of arrows, but you can hardly express this using the variable name.<br>
</blockquote></div><br><div>Ah, but this is precisely why I personally do use the "r" convention: because anywhere in the type signature where I see an "r", I know that it must match with the "result" type (the one at the end of the chain of arrows). I believe I picked up the "r" convention from Control.Monad.Cont, or possibly from Data.Conduit. This is what "r" means to me, and I think it is a convention worth pushing onto everyone else. ;)</div>
<div><br></div><div>After looking over the type signatures of Data.List, I propose the following "rule of thumb":</div><div><br></div><div>When the final result type (the one at the end of a chain of arrows)</div>
<div>of a function is a single polymorphic type with no additional structure (e.g. just "a" not "[a]" or "Maybe a"),</div><div>and the type signature of the function involves more than one type variable,</div>
<div>then the type variable appearing in the final position should be "r".</div><div>(If there is just one type variable, then it should be "a")</div><div><br></div><div>According to this rule of thumb,</div>
<div>only the following changes would be made:</div><div><br></div><div>foldl :: (r -> a -> r) -> r -> [a] -> r</div><div>foldl' :: (r -> a -> r) -> r -> [a] -> r</div><div>foldr :: (a -> r -> r) -> r -> [a] -> r</div>
<div><br></div><div>Technically this means that the "genericBlah" functions should also change,</div><div>but those have a special case of their own, which is that the integral should be "i".</div><div>
Oddly, this convention is not followed consistently, so while we're alpha-renaming,</div><div>might I also suggest that we make the genericBlah docs consistent</div><div>by using "i" for the integral, and "a" for the list member.</div>
<div>(e.g. "genericIndex :: Integral i => [a] -> i -> a")</div><div><br></div><div>Another potential reason to dislike this proposal is that</div><div>GHCi will not follow this convention, and thus</div>
<div>will not suggest the same type signature.</div><div>(Although it could be made to, since I believe I have</div><div>specified a precise algorithm.)</div><div><br></div><div>-- Dan Burton</div>