[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

Steve Horne sh006d3592 at blueyonder.co.uk
Fri Feb 3 14:21:04 CET 2012

On 03/02/2012 11:13, Gábor Lehel wrote:
> The first problem is that mixing prefix and postfix function
> application within the same line makes it harder to read. When you
> read code to try to understand what it does, the direction you like to
> go in is "here's some object, first do this to it, then do that to it,
> then do this other thing to it, then this fourth thing to produce the
> final result". In Haskell code with prefix application, this is easy:
> you read it from right to left.
I've argued before (don't think here - most likely on Programmers.SE) 
that even mathematicians think imperatively, often viewing an expression 
as if it were a right-to-left series of imperative mutations. I get 
called an idiot when I say that.


> This is the smaller problem. If prefix and postfix notations are
> completely interchangeable, then we can at least expect people to not
> make their own code hard to read, and to stick to one or the other
> within an expression. (If they're *not* interchangeable, and one or
> the other is required in some cases, then it's a bigger problem.)
There are already some right-associative operators and some 
left-associative operators. So the question isn't really about the 
language grammar, but how something "reads".

But then, even in Haskell, where order matters, most things read from 
left to right. With the monadic bind, for example, the left argument is 
"before" the right argument. In let expressions, the first definition is 
the leftmost definition. In a list or a tuple, the leftmost item is 
normally considered the first item - by definition it's the head in a 
list. When currying arguments, the leftmost argument is the first to 
curry. This isn't an absolute, of course, but still - function 
composition with the dot is arguably the odd-one out.

If the point is that TDNR should use some other symbol, I have some 
sympathy with that, but Haskells freedom with operator identifiers has a 
downside - there are few if any completely safe symbols available to 
use. Unless of course we choose a completely new character that has 
never been available before...


More information about the Haskell-Cafe mailing list