[Haskell-cafe] Some thoughts on Type-Directed Name Resolution
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