Pertti Kellomäki wrote,

...

From: Ketil Malde "Manuel M. T. Chakravarty" writes:

...

You want to be able to write

...

f 1 2 + g 3 4

...

instead of

...

(f 1 2) + (g 3 4)

I do? Personally, I find it a bit confusing, and I still often get it wrong on the first attempt.

Same here. A while back someone said something along the lines that people come to Haskell because of the syntax. For me it is the other way around. My background is in Scheme/Lisp, and I still find it irritating that I cannot just say indent-sexp and the like in Emacs. It is the other properties of the language that keep me using it. I also get irritated when I get precedence wrong, so in fact I tend to write (f 1 2) + (g 2 3), which to my eye conveys the intended structure much better and compiles at first try.

In languages that don't use curring, you would write f (1, 2) + g (2, 3) which also gives application precedence over infix operators. So, I think, we can safely say that application being stronger than infix operators is the standard situation. Nevertheless, the currying notation is a matter of habit. It took me a while to get used to it, too (as did layout). But now, I wouldn't want to miss them anymore. And as far as layout is concerned, I think, the Python people have made the same experience. For humans, it is quite natural to use visual cues (like layout) to indicate semantics. Cheers, Manuel

...

For humans, it is quite natural to use visual cues (like layout) to indicate semantics.

I agree, but let us not try to do that with just two (already overloaded) symbols.

(let ((a 0) (b 1)) (+ a b))

let { a = 0; b = 1; } in a + b is valid Haskell and the way I use the language. Enough and more descriptive visual cues, I say. Using layout is an option, not a rule (although the thing is called layout rule...)

But all this is not very constructive, because Haskell is not going to change into a fully parenthesized prefix syntax at my wish.

Thank god :-) Arjan

I realize this is a topic where it would be very easy to start a flame war, but hopefully we can avoid that. Paul Hudak wrote:

Why not have your tool generate layout-less code? Surely that would be easier to program, and be less error prone.

The tool in question is Happy, and the error materialized as an interaction between the tool-generated parser code and the hand-written code in actions. So no, this was not an option since the tool is not written by me, and given my current capabilities in Haskell I could not even fix it. On the other hand the bug is easy to work around, and it might even be fixed in newer versions of Happy.

Yes, but the layout is not ENFORCED. I programmed in Lisp for many years before switching to Haskell, and a common error is something like this:

...

(let ((a 0) (b 1) (+ a b)))

In this case the error is relatively easy to spot, but in denser code it can be very subtle. So in fact using layout in Lisp can imply a semantics that is simply wrong.

Maybe I did not express my point clearly. What I was trying to say was that because of the syntax, it is very easy for M-C-q in Emacs to convert that to (let ((a 0) (b 1) (+ a b))) which brings the layout of the source code to agreement with how it is perceived by the compiler/interpreter. So it is easy for me to enforce the layout. This is not so much of an issue when you are writing the code in the first place, but I find it a pain to have to adjust indentation when I move bits of code around in an evolving program. If there is good support for that, then I'll just shut up an start using it. After all, I have only been using Haskell for a very short period of time. -- pertti