On 09 March 2006 14:40, Simon Marlow wrote:
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.
I remember now: the problem is that 'let' does not always have a matching 'in', e.g. when it is used in 'do', pattern guards or list comprehensions. So you can't consistently treat let/in as brackets. I don't know a way around this. Cheers, Simon
On Thu, Mar 09, 2006 at 04:53:52PM -0000, Simon Marlow wrote:
On 09 March 2006 14:40, Simon Marlow wrote:
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.
I remember now: the problem is that 'let' does not always have a matching 'in', e.g. when it is used in 'do', pattern guards or list comprehensions. So you can't consistently treat let/in as brackets. I don't know a way around this.
Right, I mentioned that in my earlier mail. However, I think this can be handled by rules like L (<n>:ts) ((Let:bs,m):bsms) = L ts ((bs,m):bsms) if m = n but like I said, I haven't had time (nor do I expect to have time for H') to work it all out and see if it can actually be made to work. Incidentally, in my head the "," in "(case x of p -> e, 42)" acts as a right and left bracketing lexeme, so this expression would still be accepted. At the cost of rejecting more H98 programs you wouldn't have to allow it, of course, although from the user's point of view I'd prefer if it was allowed. (By the way, have the mailing lists started being clever and not sending you messages that look like they are also being sent directly to you?) Thanks Ian
Ian Lynagh wrote:
On Thu, Mar 09, 2006 at 04:53:52PM -0000, Simon Marlow wrote:
the problem is that 'let' does not always have a matching 'in', e.g. when it is used in 'do', pattern guards or list comprehensions. So you can't consistently treat let/in as brackets.
Right, I mentioned that in my earlier mail. However, I think this can be handled by rules like
L (<n>:ts) ((Let:bs,m):bsms) = L ts ((bs,m):bsms) if m = n
Here's a tricky case: ... | let x, y :: T x = 3 y = 4, ... The first , shouldn't close the let statement, but the second should. How do you distinguish between them? If you never allow , to close a let statement, then you can no longer write ... | let x = 3, ... Of course, the commas in type signatures and fixity declarations are redundant anyway. If they were dropped from the grammar, this problem would go away.
Incidentally, in my head the "," in "(case x of p -> e, 42)" acts as a right and left bracketing lexeme, so this expression would still be accepted.
Here's another tricky case: (case p of q | r,s -> t, ...) I'm not sure what to do about this one. -- Ben
participants (3)
-
Ben Rudiak-Gould -
Ian Lynagh -
Simon Marlow