[Haskell-cafe] types and braces

[Conor McBride]

Hi Niklas

Good to hear from you, and thanks for providing such a
useful starting point for my experiments.

On 15 Apr 2009, at 19:27, Niklas Broberg wrote:

> Hi Conor,
>
> Conor McBride:
>> The trouble is, the production I've added causes a
>> reduce/reduce conflict in the grammar, but I don't get
>> any more precise complaint than that.
>
> To get more precise complaints, you should give the -i flag to happy,
> that will cause happy to print the whole parser table into a file
> named Parser.info. It also tells you in which states the conflicts
> occur, allowing you to track 'em down.

So that's how you do it! I was expecting that some such thing
would exist.

>
>
>> I guess what I'd like to know is whether I just need to
>> debug my grammar extension, or whether the notation I'm
>> proposing actually introduces a serious ambiguity that
>> I'm too dim to notice. I'm mostly sending this in the
>> hope that I have one of those "d'oh" moments you
>> sometimes get when you articulate a stupid question in
>> public.
>
> 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.

I can use (|...|) as the brackets I need in the meantime,
without even disturbing the lexer, but I'd much rather
use {...} if I can learn a bit more happy hacking. My
efforts so far have been clumsy and frustrating, but -i
might help me see what I'm doing wrong.

Subtle stuff

Conor