Hacker News Reader

Comment by thomastjeffery | Hacker News Reader

I really dislike the $ operator. If you need to change precedence, use parenthesis.

Does that mean more typing? Yes. Does it mean better readability? Yes.

It's not like you are typing that much code in the first place! The goal of Haskell should not be maximum terseness: it should be elegance.

View on HN

The use here is as a section, not to change precedence: `($ x)` could also have been written as `\f -> f x`, which I think is even less readable.

As for the usage on the lower code snippets like `for […] $ \x -> …`, then it saves some parentheses. Opinions on this go both ways, with some people preferring lisp-style syntax, others use more Python-like indentation code formatting. Both are okay, and I’ve switched my preference multiple times.

Where I agree $ is terrible is in expressions like `foo x . bar y z $ abc`, often (!) much harder to read than just adding parentheses.

> Where I agree $ is terrible is in expressions like `foo x . bar y z $ abc`, often (!) much harder to read than just adding parentheses.

This case is actually valuable for the clear delineation of the lefthand-side that's relatively fixed and can be moved to an outer scope (or even toplevel) and the righthand-side that's contextual and is dependent on a more dynamic value-part.

I really liked $ when I was writing Haskell one-liners because it behaves like a UNIX pipe. You can trivially reason about a system of pipes.

During the same voyage, almost no uses of dot - it might be super elegant when writing complex functions for something else, but not for doing things.

I write haskell daily. A well placed $ is MUCH, MUCH more readable then deeply nesting parenthesis.

Stacking dollar signs is elegant to me

    f
  $ g
  $ h
  $ some expression etc

If I'm not mistaken, it reads from bottom to top. I hated the function application direction my whole life, even in math (I read and write from left to right, so f applied to x should be x f, and g after that should be x f g), but it is ridiculously bad in Haskell. Transforming data, filtering and piping should be where it excels due to the lazy data structures, but bottom to top piping order is annoying.

I prefer it, personally. Especially when pointfree. Way easier for me to read at a glance.

You can use `>>>` from `Control.Arrow` to switch the order if you don't mind make your code more esoteric.

Control.Arrow is in base at least :)

The & operator in Data.Function--which is just flipped $ with slightly higher, but still very low, operator precedence--at least gives you a way to deal with this in base; it's unfortunate it isn't more widely used in tutorials and example code (at least from what I've seen).

For chains of function applications, `$` is more readable than like 5 nested parens, especially if the thing at the end of your `f $ g $ ...` is a do-block, which will span multiple lines.

My preferred way is `(f . g . h) x`: parentheses have good editor support, are very readable when there aren’t that many.

That's good too, but you still need one $ for a do block.

Not with -XBlockArguments you don't :)

I did not know about that! Nice

It's actually been around since 8.6.1 but I personally have only started using it recently. There are certain situations where it's much nicer than $

I will always have a nostalgic love of `$ do` though :)

It's just a infix id, there's nothing special about it. You also object to infix + I suppose?

Reply on news.ycombinator.com