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