Re: Subrule ordering

[h. w. neff]

Richard Jelinek wrote:
 
 On Fri, Jun 13, 2003 at 01:33:58PM -0700, Ron D. Smith wrote:

 But still I don't get why a
 
 rule:   prod1
   | prod1 and something
 
 won't work. Why always the longest prefix productions have to stand
 first. I even suspect a flaw in the docs as when the parser encounters
 an input string that'd match prod1 and something it should fail with
 prod1 and try the second production. In fact it doesn't it throws the
 complete rule away after failing the first production and simply
 states, that input string could not be parsed.
 
 That bothers me from a pedantic point of view.

bear in mind that p::rd is not a greedy parser like something
   you might build with lex/yacc.
order is important because it won't do them all and pick the one that
   consumes the maximal amount of the input text.
i.e. it will, like your kids (or mine at least :-), quit just as soon
   as it's done the minimum it can to get by according to what you've
   specified.
hwn

Re: Subrule ordering

[Ron D. Smith]

On Friday, Jun 13, 2003 Richard Jelinek said:

 Hi Descendants od Rec.
 
 Subrule/production ordering. I just don't get it.
 
 given this grammar
 
 return new Parse::RecDescent (q{
meaning: proplist
{ if(length($text)) {
   print $text remains unparsed.\n;
   return undef;
  }
  1; }
  | { return undef; }
 
   property:phrase '(' proplist ')'
  | '(' proplist ')'
  | '~' property
  | phrase
 
 
   proplist:property xor_prop(s?)
  | property and_prop(s?)
 
   xor_prop:'|' property
   and_prop:',' property
 
 
   phrase:  /[^\(\)\=\,\|\\~]+/
 
 });
 
 when I try to parse 'SYN(d(e|f))'
 
 everything goes well. If the string is 'SYN(d(e,f))', a syntax error
 is spilled out. If I swap the first two subrules/productions of
 proplist, the situation is vice versa.

Ordering is how you establish priority in ambiguous situations.  If you turn 
on $::RD_TRACE=100 you will see what the parser is doing.  If you follow the 
second SYN(d(e,f)) case you will see that the parser is correct, the grammar 
you describe does not parse that input.  Its not a problem with the order, 
its a fundamental problem with your grammar.  So its not that you do not 
understand the ordering rules, its that you do not understand your grammar.

This successfully parses both, but I'm, not sure its what you want.

$::RD_TRACE=100;

$it= new Parse::RecDescent (q{
   meaning: proplist
   { if(length($text)) {
  print $text remains unparsed.\n;
  return undef;
 }
 1; }
 | { return undef; }

  property:phrase '(' proplist ')'
 | '(' proplist ')'
 | '~' property
 | phrase


  proplist:property xorand_prop(s?)

  xorand_prop: xor_prop|and_prop
  xor_prop:'|' property
  and_prop:',' property


  phrase:  /[^\(\)\=\,\|\\~]+/

});

$it-meaning('SYN(d(e|f))');
$it-meaning('SYN(d(e,f))');

 
 I found nowhere in the Parse::RecDescent docs, that the ordering of
 productions does matter. But it seems it does. If there isn't
 something blatantly evident I've overseen this makes writing and
 maintenance of these grammars harder than it could be.
 
 -- 
 best regards,
 
  Dipl.-Inf. Richard Jelinek
 
  - The PetaMem Group - Prague/Nuremberg - www.petamem.com -
  -= 2325182 Mind Units =-

--
 Intel, Corp.
 5000 W. Chandler Blvd.
 Chandler, AZ 85226

-- 
 Intel, Corp.
 5000 W. Chandler Blvd.
 Chandler, AZ  85226

Re: Subrule ordering

[Richard Jelinek]

On Fri, Jun 13, 2003 at 11:24:05AM -0700, Ron D. Smith wrote:
 Ordering is how you establish priority in ambiguous situations.  If you turn 

This is an interesting aspect/information.

   proplist:property xorand_prop(s?)
 
   xorand_prop: xor_prop|and_prop
   xor_prop:'|' property
   and_prop:',' property

Actually this does also:

  proplist:property xor_prop(s)
 | property and_prop(s?)

without the xorand rule. And now I understand this construct and why
it does work. But this doesn't change anything it just pushes the
problem one step further.

You say, ordering is to establish priority in ambiguous
situations. Well - given this rule:

(I)

order_sensitive:phrase
  | phrase '(' blah ')'

Ambiguity? Yes. But this NEVER gets to the second production. While

(II)

order_sensitive:phrase '(' blah ')'
  | phrase 

parses all well, I really don't have a choice to set priority with
ordering. Probably my input has more non-parameter phrases than those
with parameters. No matter what, I have to use the inefficient (II).
With my present knowledge - that is.

-- 
best regards,

 Dipl.-Inf. Richard Jelinek

 - The PetaMem Group - Prague/Nuremberg - www.petamem.com -
   -= 2325182 Mind Units =-