the dreaded offside rule

[Simon Marlow]

On 09 March 2006 14:33, Ian Lynagh wrote:

> On Wed, Mar 08, 2006 at 10:27:48PM +0100, Doaitse Swierstra wrote:
>> It is with some hesitation that I want to bring up another point, in
>> which Haskell' could be an improvement above Haskell: the offside
>> rule. 
> 
> This is something I would have brought up too, except I don't think
> I'll have time to look into it properly in the advertised timescale.
> 
> I conjecture that with a suitable set of bracketing keywords and
> symbols (if/then, let/in, [/], ...) the "parse error => close
> implicit block" rule could be dropped without significantly altering
> the set of acceptable programs (just rejecting programs that people
> really oughtn't be writing anyway (IMNSHO), like Lennart's examples).

I once conjectured this too, and I even went so far as to measure how
many times the parse-error rule was actually used, as opposed to simple
bracketting, in all the code I could get my hands on.  Conclusion: it
was a handful of times in several 10000 LOC, mostly for things like
'(case x of p -> e, 42)'.

But ISTR I later discovered a reason that counting brackets wouldn't
work so well, but for now it escapes me.  I'll try to dig it up.

> Things are slightly complicated by things like [ ... | ... ] and "let"
> not always being closed by "in" (so you just have to have it
> implicitly closed when you want to insert a ; in a "do" block), but I
> haven't thought of anything that'll actually break it. Then again, I
> haven't thought too hard about it or tried it out yet.
> 
> I'm not sure how much easier this will make it to explain the rule to
> people - if you just explain the gist using the simple examples of
> bracketing, like if/then, then I think it would be significantly
> simpler, but if you'd want to explain all the niggly details then it
> might end up also being too complex.
> 
> The main advantage is it would make layout a separate pass between
> lexical analysis and parsing.

Yes, and that's a big win.

Cheers,
	Simon