[boothead]

Which syntaxes are you referring to?

Without knowing which one's you mean, can I offer a suggestion: Instead of looking at these syntaxes and more overhead, (feeling that you need to somehow mentally parse them into whatever they de-sugar to) try to treat them more as a chunking [1] opportunity.

So for example, when you see code in a monadic do block, don't try to mentally de-sugar it to the function calls it results in. Rather think of it slightly like imperative code where x <- someMonad ~ x = someMonad(). This of course isn't what's going on really, but in many cases it's close enough for you to use it and move on.

[1] http://en.wikipedia.org/wiki/Chunking_%28psychology%29

[tomwilde]

Thanks. I am referring to, for instance, the 'method notation' introduced in that article.

I think I know what you mean by chunking. It is my understanding that it is a counter-productive thing, though. Just like how with 'frameworks' imperative programmers lose perception of the technical debt they incur by not knowing what their code actually does.

Maybe this line of thought is not universal but I'd presume the majority of programmers would be afraid to submit code to a project where they don't really know the notational mix and syntactic sugar in use.

[tel]

Syntax sugar in Haskell tends to be different than other languages. Since it's essentially just do-notation and do-notation follows monads and monads are required to follow a hearty chunk of behavioral laws... It's actually quite similar across the board what do-notation means. This makes chunking far more effective.