[Haskell-cafe] Re: Arrows: definition of pure & arr

[Ben Franksen]

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