[astine]

That's the neat thing about Lisp-style macros. You have to sacrifice a little bit of the syntactical sugar that you are used to in most languages, but in return you have the ability to add almost any possible construct to the language natively. It makes it much easier to extend the language as you don't need to hack an interpreter written in C or Java. Half of the core language is already written in macros.

[seacious]

Not having to memorize an operator precedence table makes me more than willing to give up syntactic sugar. This is one of the things that I dislike most about haskell. I wish liskell or one of the other projects trying to bring S-expressions to haskell had taken off.

[awj]

If I have the slightest concern about operator precedence while writing code, I put in extra parens. Because it will definitely hinder me reading the code later. Plus, Haskell doesn't use them much anyways. I'm sure the 9 and 0 keys get lonely.

[thinkpad20]

With haskell's type system most precedence errors are caught quickly. Precedence generally follows intuition: PEMDAS of course, and then the idea that control-flow operators like >>=, <|>, etc should be lower precedence, while operators that tend to group expressions together like (.) should be high-precedence. Of course a lot of the time it's somewhat arbitrary, but this is because a lot of the time it just doesn't matter. In cases where things aren't clear, you can always choose to use parentheses.

[dominotw]

>Not having to memorize an operator precedence table makes me more than willing to give up syntactic sugar.

Really? This is such a big problem that you have to choose a completely different language.

[seacious]

Knowing what the AST looks like without having to sit an think about it is huge. Maybe you're smarter than me and can instantly intuit it, but I think most people can't. I think that this is one of the reasons that macros are so widely adopted in LISPs but not in other languages that support them. Having an immediately evident AST makes it much easier to reason about, and hence to manipulate either through code or manually.

Edit: Improve clarity.

[chongli]

There's nothing stopping you from using more parens in your own Haskell code; I definitely use them.

[Periodic]

I find if I'm using parentheses to group (non-numeric) expressions in Haskell then I should probably break up the expression and name the parts.

One wonderful thing about Haskell is that there isn't a cost to using let expressions, even if some of the values will never be used. Laziness means I can freely decompose my complex expressions into clearly named components and not worry about doing unnecessary computation.

[psibi]

In that case you can either use $ or parenthesis in Haskell. I personally find the code neat without any parenthesis noise.

[zoowar]

While this is a reasonable approach, it quickly breaks down when you look at code written by others who do not follow this approach.

[jarrett]

When approach X isn't followed, approach X breaks down? True for all approaches, no?

Any language can be written poorly. I don't think any language will ever be able to force good coding style on programmers. Though Haskell comes closer to that impossible goal than many other languages, due to its type system, functional purity, and mandatory indentation.

[lgas]

The difference is that in lisp you cannot chose to not "follow the approach" because the approach is fundamental. So you will never look at anyone else's lisp code and see that they chose not to use parentheses uniformly.

Well, technically it's possible if someone used macros to embed a DSL that is paren free, but it just doesn't happen in the vast majority of cases. Whereas if you try to follow the approach of using parens everywhere in Haskell, the vast majority of other code you attempt to read will still be awkward for you.

[zck]

There's a common complaint in this thread that is basically "just write your code better, then it'll be readable." There's also a common praise of Haskell that says that its type system eliminates entire classes of errors. It's not accepted by people who use Haskell that "if you use another language and just write your code better, you don't need a type system."

Having to explicitly indicate the precedence of operators -- as in Lisp's prefix notation -- completely eliminates precedence errors, both in writing and in reading. This is true even though "well-written"^1 code using implicit infix notation is readable.

[1] Note also that the level of implicit precedence that you're comfortable with might be different from mine.

[vorg]

The original infix operators and their precedences were natural to reason about...

  * /
  + -
  = !=
  &&
  ||

Of course you can always use an infix macro in Clojure, e.g. http://data-sorcery.org/2010/05/14/infix-math/

[JackMorgan]

There _was_ a project to add s-exprs to Haskell?! Hopes raised and dashed in the same five seconds! I'm a seasoned lisper learning Haskell, and trying to figure out when this parameter will go where is driving me crazy. "No you stupid compiler, I'm passing this to that, not the other way arrrg!"

[dllthomas]

Of course, when writing Haskell, you could always just wrap the individual operators in parentheses and get the prefix forms (as distinct from fully parenthesizing to disambiguate with infix forms). Getting others to do so (and getting them to merge your code) may be an uphill battle, though...

[mjs2600]

Elixir has Lisp-style macros with a Ruby syntax. It's not quite as close to the AST as a Lisp, but I think the trade off hits a sweet spot. For example:

  quote do
    1 + 1
  end

returns:

  {:+, [context: Elixir, import: Kernel], [1, 1]}

which, if you squint at it, starts to look a little Lispy.