Richard O'Keefe wrote:

After all, someone might have started with ( "(" ++ str ++ ")" ) and ended up with ( "(" ++ str ++ ")" -- (oops, no ++!) lineEnd -- forgot I needed this )

I asked for the trailing comma in Erlang for _social_ reasons, not because I believed it would fix all problems of this type.

What do you mean, for social reasons? And are there any projects/feature requests to add the trailing comma to ghc? As for "all problems of this type", I agree in theory, but often enough, for an operator @@, you can use foldl1 (@@) [...] and reduce it to the trailing comma problem (notable exceptions include (.) and ($) and other operators where the type is different for the intermediate return values -- and this, I take it, is why '$#' is in the proposal). If I need to use 'a @@ b @@ c' for any operator @@, I rewrite it with a fold (if possible), because I find it more readable to not repeat the operator over and over again. I find lists more semantically appealing in this situation: you really are listing things.

Actually, I'd write

main = getChar >>= \a -> bracket_ (enter a) (exit a) (putChar a >> putStrLn "hello")

so even _with_ this proposal, I'd still need exactly the same parentheses.

Doing monads without do-notation gets me into precedence trouble pretty quickly -- I find myself adding lots and lots of parentheses, until it ends up looking like Lisp (which I've always found hard on the eyes, keeping track of how many layers you have -- indentation is better for this, in my opinion). The fact that $ can't be used for the last expression of the bracket_ is an example of the precedence trouble I get into. I agree that this proposal makes a lot less sense if you don't also use do-notation.

Where I'm coming from is this: I do not find meaningless jumbles of special characters combined with overloaded white space readable.

I find the combination of characters very meaningful and intuitive, especially if '(#' is chosen over '#(': use an # if you want to put a list on separate lines (which you'd lay out like that anyway: why not give the compiler some extra knowledge), and don't use it if it fits on the same line. I don't see how this is all that revolutionary, especially as we already have whitespace-significant and non-whitespace-significant versions of 'case', 'do', etc. I don't even see it as syntactic sugar, but more as an alternative syntax -- with the exception of '$#' it parses pretty much directly to the same tree, does it not? It's just changing what's significant. I am not at all committed to the specifics. Would it be better if there were keywords like 'list#', 'tuple#', or maybe '(#)', '[#]' etc? I would suggest using colon like Python, except for it's taken by the (:) operator. I guess where I'm coming from is: I don't like my expressions to be full of parentheses or hard-to-track operator precedences, and find it harder to read, to write, and to maintain, even for toy examples like the ones we've been discussing.