[Haskell-cafe] accessible layout proposal?

[Richard O'Keefe]

On Sep 23, 2009, at 3:04 PM, Evan Laforge wrote:

>> It would be so much better if we could discuss a _real_
>> example.
>
> Or implement one.

I really did mean EXAMPLES.  Examples of code which would
be improved *more* by the proposal than by adopting an
alternative style within the existing language.

Let's not forget what the proposal actually _is_.
It is that "#(" "#[" "#$" and "#" should become magic
tokens such that

	#( {a;b;c}  is read as  (a,b,c)
	#[ {a;b;c}  is read as  [a,b,c]
       f #$ {a;b;c}  is read as  f (a) (b) (c)
         #  {a;b;c}  is read as  {a,b,c}

[http://www.haskell.org/haskellwiki/Accessible_layout_proposal]

Are you not troubled by the inconsistencies here?
Why isn't the last case #{ to match #( and #[?
Why does #$ add extra parentheses but not the others?

Are you not troubled by the fact that it breaks the automatic
bracket matching in editors like Vim, Emacs, XCode, ...?
I _can_ hack on Emacs if I have to, but I _can't_ hack on
XCode.  In fact it breaks bracket matching in two ways:
  - clicking just after #( doesn't select the tuple the
    way that clicking just after ( does
  - the excess imbalanced bracket wrecks matching for
    anything that includes an #( or #[

That's a *lot* to give up for less readable code!

In effect, the proposal is that there should be a context-
sensitive overloading of <newline> to mean
	- nothing  (existing case)
	- semicolon (existing case)
	- >> or >>= (existing case)
	- comma (for #( and #[ and #)
	- nothing, except parentheses magically go somewhere else

That's too many overloadings for me.  'do' was already too
many overloadings for me to be comfortable with, which is
one reason why I avoid it.

On small examples, I find no advantage.

Let's see a real medium-size example.
The heavy costs that I can see might just be overwhelmed by
advantages in real use.