Conor,
I'd like to point out a few things that may help you on the way.
On Wed, Apr 15, 2009 at 8:58 PM, Conor McBride
I don't immediately see what the clash in that context would be - I *think* what you propose should be doable. I'd be interested to know what you come up with, or I might have a look at it myself when I find a few minutes to spare.
I've found that I can add a production
atype :: { Type } ... | '{' trueexp '}'
if I remove the productions for record declarations
constr1 :: { ConDecl } | con '{' '}' { RecDecl $1 [] } | con '{' fielddecls '}' { RecDecl $1 (reverse $3) }
which suggests that it is indeed the syntax
data Moo = Foo {goo :: Boo Hoo}
which is in apparent conflict with my proposed extension. The current parser uses the type parser btype to parse the initial segment of constructor declarations, so my change causes trouble.
Further trouble is in store from infix constructors
data Noo = Foo {True} :*: Foo {False}
should make sense, but you have to look quite far to distinguish that from a record.
So I don't see that my proposed extension introduces a genuine ambiguity, but it does make the parser a bit knottier.
Remember that even though your parser in unambiguous that doesn't mean that happy will be able to handle it. Happy deals with LALR grammars and you have to confine yourself to that restriction in order to make happy happy. Also, your example above suggests that your grammar might require an infinite lookahead, something which happy doesn't deal with. Having said all this, there is a magic flag which you can give to happy which will make all these headaches go away. The incantation is --glr which makes happy produce generalized lr parsers which can deal even with ambiguous grammars. I've never used this myself so I can't give you any further advice than to point you in the general direction. The happy manual is your friend. Happy happy hacking. Josef