[Haskell-cafe] accessible layout proposal?

[Jimmy Hartzell]

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.