[Haskell-cafe] accessible layout proposal?

[Richard O'Keefe]

On Sep 23, 2009, at 3:40 PM, James Hartzell wrote:
>> 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?

The proposal is http://www.erlang.org/eeps/eep-0021.html

The abstract says "Allow an extra comma at the end of a list
or tuple.  Darren New proposed this change; Richard O'Keefe,
who doesn't like it very much, wrote it up as an EEP."

Later on, we find the text
"I don't actually feel any need for this proposal;
I believe that the answer is better tool support.
However, many people are wedded to their tools, even more than
their programming languages. Darren New is not the only one to
have asked for it, and with about 1 SLOC in 110 of the Erlang/OTP
sources reflecting a list or tuple where this feature could have
been used, it's very much a low cost high public appreciation
feature."

It was a feature that people *wanted* because they were used
to in other languages and it could be added at comparatively
low cost (there's only one Erlang implementation worth
bothering about) without breaking existing tools.  Adding it
would please many existing and potential Erlang programmers
without XXXXing off too many others (you don't _have_ to
write the extra comma, and it's not that obtrusive when you
read other people's code), and it would remove some complaints
and criticisms from the mailing list, so, social reasons.
I don't believe it solves any problem that can't be better
solved any other way, but at least optional trailing commas
don't *hurt* anything.

This might actually be different in Haskell, which allows
things like (,,).  You can't add a trailing comma here
without breaking things.

The #( #[ #$ # proposal, on the other hand,
WOULD break things.  "#" is currently an 'ascSymbol',
so the character sequences #( and #[ may occur in
legal Haskell code.

infix #

x # y = (x,y)

foo x y = x #( y )

bar x z = x #[ z ]

> 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).

I am a bit puzzled here.
This seems to mean something like
  "If you take readable code using an operator you can
   make it less readable, and when you do that you create
   another problem as well, and an even less readable hack
   can fix that."

"I know an old lady who swallowed a fly..."

> I don't see how this is all that revolutionary,

I don't think anyone claims that it is.
The claims are that it is
  - not needed
  - not pleasant to look at
  - not good for existing syntax-(semi-)aware tools
  - not backwards compatible with existing code

> I am not at all committed to the specifics. Would it be better if  
> there
> were keywords like 'list#', 'tuple#', or maybe '(#)', '[#]' etc?

But of course!
>

> 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.

There's no accounting for taste.

I find invisible operators much harder to deal with than
parentheses.

So we agree to differ.

Changing the proposal to something that doesn't spoil bracket
matching and doesn't break previously legal Haskell' code
(note the prime; I'm not fighting old battles again) would
make a huge difference.  I still wouldn't _like_ it, but
wouldn't have such strong reasons to _oppose_ it.

For what it's worth, I've used an experimental language
where
  - immediately after ( [ { or an infix or prefix operator,
    newlines were treated like any other white space
  - in other contexts, newlines inside ( [ were treated as
    commas
  - in other contexts, newlines were treated as semicolons
  - trailing commas and semicolons were allowed

In Haskell terms, this would mean that

     (
	1
	2
	3
     )

meant (1,2,3) and

     [
	1
	2
	3
     ]

meant [1,2,3] and 'do' and 'case' worked as now.

By adding

     f $$ (x,y) = f x y
     f $$ (x,y,z) = f x y z
     f $$ (x,y,z,a) = f x y z a
     ...

you could also have

     f $(
	1
	2
	3
     )

meaning f 1 2 3.
I am aware that this is not backwards compatible with existing
code, and I am not proposing this for adoption.