Wolfgang Jeltsch wrote:
I’m also in the process of shortening the names for type variables since in conference papers you cannot use names that long (because otherwise you quickly overrun the available width) and I don’t want to have too many differences between papers and actual source code. However, I still don’t like single-letter names like a and b.
I like them if the type variables are really completely arbitrary types, like in map :: (a->b) -> [a] -> [b]. Using longer and more descriptive names here would (IMHO) be a mistake, as there is nothing specific about them. Similar on the value level, a definition like map f (x:xs) = f x : map f xs is (IMO) rather /easier/ to understand than anything using longer and more descriptive names, as, again, what x stands for is completely irrelevant here. I'd like to mention in passing that according to Dijkstra, when we develop an abstraction, it is important to (at least temporarily) forget what the symbols originally stood for, that is, before we abstracted them out of the context in which they originally appeared. The advantage is that without 'intuition' (about what the symbols 'mean') we have nothing left to follow but logic, which (supposedly) leads to a clearer understanding of the abstraction in itself, which in turn leads to shorter and more concise proofs, i.e. programs. That said, there are many situations where the type variables are linked by constraints and additional type (e.g. class method) signatures. In this case, mnemonic names can be a great help to understanding. In the example given, I'd use one-letter abbreviations of teh longer names, i.e. create :: PlainCircuit i o -> i -> IO (o, IO ()) Cheers Ben