camlp4 grammar and LIST1

camlp4 grammar and LIST1

[Joel Reymont]

In the following bit of camlp4 grammar

   inputDeclarations:
   [
     [ "Input"; ":";
       l = LIST1 inputDeclaration SEP "," -> l
     ]
   ];

Is it always necessary to write [ x = inputDeclaration -> x ] instead  
of just inputDeclaration?

I'm trying to debug the type of each rule and I'm often getting  
complaints about 'unit list' being used instead of just 'statement'.

By the same token, can I shorten the gramar below to just  
[ openStatement | closedStatement ]?

   statement: [ [ s = openStatement -> s | s = closedStatement -> s ] ];

How do you folks debug grammar rule types?

	Thanks, Joel

---
http://tinyco.de
--- Mac & iPhone

Re: [Caml-list] camlp4 grammar and LIST1

[Jake Donham]

On Tue, Mar 10, 2009 at 11:41 AM, Joel Reymont <joelr1@gmail.com> wrote:
>  inputDeclarations:
>  [
>    [ "Input"; ":";
>      l = LIST1 inputDeclaration SEP "," -> l
>    ]
>  ];
>
> Is it always necessary to write [ x = inputDeclaration -> x ] instead of
> just inputDeclaration?

I don't think this is ever necessary (although in the back of my mind
I have a fuzzy recollection that somewhere in the docs / wiki it says
that it is). I can't say why you got a type error one way but not the
other.

For debugging types, you might find it helpful to look at the output
of the preprocessing step, which has various type annotations.

> By the same token, can I shorten the gramar below to just [ openStatement |
> closedStatement ]?
>
>  statement: [ [ s = openStatement -> s | s = closedStatement -> s ] ];

Syntactically it is fine but I don't think this is going to do what
you want. Camlp4 parsers aren't backtracking; you have to distinguish
openStatement from closedStatement by parsing a token. Otherwise
you'll always follow the openStatement branch, then get a parse error
if the stream wasn't actually parseable as an openStatement. (I think
this is correct but it has been a few months since I worked on a
grammar, sorry if I remembered it wrong.)

Jake

Re: [Caml-list] camlp4 grammar and LIST1

[Joel Reymont]

On Mar 10, 2009, at 9:48 PM, Jake Donham wrote:

>> statement: [ [ s = openStatement -> s | s = closedStatement -> s ] ];
>
> Syntactically it is fine but I don't think this is going to do what
> you want. Camlp4 parsers aren't backtracking; you have to distinguish
> openStatement from closedStatement by parsing a token.

I have it like this at the moment. Are you saying it won't work?

What does it mean to parse a token then?

Does that token have to be in the same rule?

	Thanks, Joel

---

   statement: [ [ openStatement | closedStatement ] ];

   openStatement: [ [ openIfStatement ] ];

   openIfStatement:
   [
     [ "If"; e = expr; "Then"; s1 = closedStatement; "Else"; s2 =  
openStatement -> If (e, s1, s2)
     | "If"; e = expr; "Then"; s = statement -> If (e, s, Skip)
     ]
   ];

   closedIfStatement:
   [
     [ "If"; e = expr; "Then"; s1 = closedStatement; "Else"; s2 =  
closedStatement -> If (e, s1, s2) ]
   ];

   closedStatement:
   [
     [ inputDeclarations
     | varDeclarations
     | arrayDeclarations
     | compoundStatement
     | assignment
     | closedIfStatement
     | whileStatement
     | forStatement
     | tradeStatement
     | preprocessorStatement
     | procCall
     ]
   ];

   inputDeclarations:
   [
     [ "Input"; ":";
       l = LIST1 [ x = inputDeclaration -> x ] SEP "," -> InputDecls l
     ]
   ];
   ...

---
http://tinyco.de
--- Mac & iPhone

Re: [Caml-list] camlp4 grammar and LIST1

[Jake Donham]

On Tue, Mar 10, 2009 at 3:07 PM, Joel Reymont <joelr1@gmail.com> wrote:
> I have it like this at the moment. Are you saying it won't work?

Here's an example of what I'm talking about:

  open Camlp4.PreCast
  let bar = Gram.Entry.mk "bar"
  let baz = Gram.Entry.mk "baz"
  let bar_or_baz = Gram.Entry.mk "bar_or_baz"
  ;;
  EXTEND Gram
  bar : [[ LIST0 "quux"; "bar" -> () ]];
  baz : [[ LIST0 "quux"; "baz" -> () ]];
  bar_or_baz : [[ bar | baz ]];
  END
  ;;
  Gram.parse_string bar_or_baz Loc.ghost "quux quux baz"

The given string does not parse because we've already committed to the
bar branch.

However, several variations I tried did not show this behavior (e.g.
only one quux in the string). I think there are some special cases,
although they are not documented anywhere I have found. An approach
that works for me is to think "recursive descent" and always give
rules that check at least one token before branching to another rule.

Jake

Re: [Caml-list] camlp4 grammar and LIST1

[Joel Reymont]

On Mar 10, 2009, at 11:01 PM, Jake Donham wrote:

> An approach
> that works for me is to think "recursive descent" and always give
> rules that check at least one token before branching to another rule.


Something like this then?

   sellMethod:
   [
     [ "Next"; "Bar"; at = OPT "At$"; e = expr;
       f = [ [ "Stop" | "Lower" ] -> fun x -> Stop x
           | [ "Limit" | "Higher" ] -> fun x -> Limit x
           ] -> (f e, at)
     ]
   ];


---
http://tinyco.de
--- Mac & iPhone