Simon Marlow <[EMAIL PROTECTED]> wrote,
> > Does anybody disagree with my interpretation of the standard? Are
> > there any implementations that actually follow the standard here?
> > (Maybe the standard should be changed to follow the implementations in
> > this area.)
>
> Phew. Well spotted. Of course, none of the existing Haskell
> implementations are in conformance here.
>
> I think this has just about convinced me that the parse-error condition is a
> really bad idea.
It definitely is.
> The main reason for its inclusion was to allow things like
>
> let f x = x in ...
>
> and also to automatically insert the final '}' before the end of file.
> Perhaps the layout rule should be restricted to these two cases?
>
> Proposal:
>
> - replace t by 'in' in the parse-error rule.
>
> EOF is already handled by the last clause in the layout spec. My guess is
> that this would break very few programs.
The problem with this fix is that layout for let-in and
other grouping constructs would be handled differently,
which is not very intuitive. The problem with the
`do'-notation also appears for `case'-constructs.
> A simpler rule might involve automatically inserting '}' before 'in' during
> lexical analysis iff (a) we're in a layout context and (b) the close brace
> hasn't already been inserted by the layout rule. This would decouple the
> parser and lexer which is a Good Thing.
Still not intuitive, but from a syntactical point of view
much more preferable. But you want to change (b) to ``the
last lexeme was no close brace'' (it may have been
explicitly inserted by the programmer.
IMHO, in the long run (= next version of Haskell) this rule
should completely vanish. So, who is collecting the
proposals for the next Haskell standard?
Cheers,
Manuel
