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.