layout rule infelicity

[Jon Fairbairn]

> I like layout but I think the existing rules are too
> complicated.  Unfortunat ely it's difficult to do anything
> with them without breaking vast swathes of existing code,
> so we'll just have to put up with them.

Well, there's two things to consider: Haskell 98, which
probably shouldn't change, and extended Haskell, which
probably should. Especially if we can make the rules both
simpler and better.

> The reason I think layout is better than using {'s and ,'s is that huma=
ns
> use the layout to group the structure anyway, which means you can have =

> confusing situations where a structure looks alright to a human but not=

> to a computer.

Which is exactly the problem with the programme I
posted. Having thought about it a bit, it strikes me that
the particular problem is the insertion of a closing brace.
=46rom the human reader's point of view, there's no visual
equivalent of the closing brace in the example:

> possible_int =3D do skip_blanks
>                   fmap Just int
>                   +++ (literal "-" `as` Nothing)

What happens is that a semicolon is inserted because the
indentation is the same as the previous line -- that's fair
enough, subject to some quibbles about treating all
expressions the same -- but then the +++ is a syntax error
unless a closing brace is inserted.

Visually, the equivalent of a closing brace is when
indentation is less (to my eye it ought to be right down to
where the 'do' is and inbetween be an error).  What's wrong
with the notion that closing braces should only be inserted
when the indentation is less (or the file ends)? This would
reject some programmes, but only ones where the appearance
is misleading.

So =


> possible_int =3D do skip_blanks
>                   fmap Just int
>                    +++ (literal "-" `as` Nothing)

> whatever ...

parses as =



> possible_int =3D do {skip_blanks
>                   ;fmap Just int
>                     +++ (literal "-" `as` Nothing)

>                   }
> whatever ...

and

> possible_int =3D do skip_blanks
>                   fmap Just int
>                   +++ (literal "-" `as` Nothing)

> whatever ...

parses as =


> possible_int =3D do {skip_blanks
>                   ;fmap Just int
>                   ;+++ (literal "-" `as` Nothing)

>                   }
> whatever ...

and then gives a syntax error

but =


> possible_int =3D do skip_blanks
>                   fmap Just int
>                  +++ (literal "-" `as` Nothing)

> whatever ...

parses as =


> possible_int =3D do {skip_blanks
>                   ;fmap Just int
>                   }
>                  +++ (literal "-" `as` Nothing)

> whatever ...

Which is just about acceptable to me, because the +++ does
stick out, though I'd prefer that one to be rejected too.

I wasn't fit enough to follow the earlier discussions of the
layout rule, so I'm not sure how this interacts with
previous awkward cases.  I'd be happiest if we could come up
with a rule that didn't involve sticking in braces and
semicolons because it won't parse otherwise. Can someone
remind me why the "A close brace is also inserted whenever
the syntactic category containing the layout list ends" part
of the rule is there?

  J=F3n


-- =

J=F3n Fairbairn                                 Jon.Fairbairn@cl.cam.ac.u=
k
31 Chalmers Road                                         jf@cl.cam.ac.uk
Cambridge CB1 3SZ            +44 1223 570179 (after 14:00 only, please!)