Hi Yves,
> "Orton, Yves" schrieb:
>
> > no, you didn't really catch my problem. I'll try it again:
>
> Actually I do. But thats ok.
ok
> > ipaddr = "10.0.0.1";
> > passw = "private";
> > ipaddr = "192.168.10.1"
>
> Why should this _necessarily_ fail. This could be a backup machine right?
sure, but that depends totally on the application dealing with this
cfg file. If for this cfg file only one option is handled then this is
typically a typo by the user, and think about #include features, the
user will sometimes get lost and then the parser has to help him.
It's the same with programming, you appreciate also perl -w :-)
> (The point here is that you have a bunch of contextual constraints that derive
> from the fact that these symbols (words) have meaning. P::RD does not
> understand meaning, all it looks for is patterns, and then translates them
> into actions/data structures)
The symbols have no special meaning, the problem is the missing
order for the symbols.
P::RD understands constraints already very much, all modifiers
and all directives introduce contextual constraints, it's just a matter
of standpoint. These additional meanings for e.g.
subrule! and subrule ^ subrule are not different to lookaheads, rejects,
commits and the usual production rules.
>
> > and I see no chance to do this without {action code}.
>
> As i said in my earlier post this is correct, but (sorry) trivial. Modify the
> sub I gave you there to suit your needs and plug it in where you need
> contextual considerations.
The matter is not that I can't do this with action code (in fact
I do this quite regularly) but as I can see, the grammar get's scattered
over productions and action code and is hard to understand and maintain
by third persons.
statement: A! | B! | C | D
is so easy to understand: At least A and B, optionally C and/or D
but without ORDER, in comparison to action codes and greps and maps
and line noise.
> I dont think that this would generalize well. Tell me what the following
> should do
>
> toplevel : rule(s)
> rule : A ^ B ^ C | A ^ C | A | B
I think there is no ambiguity for the parser generator, nevertheless
the requirements are strange but even imaginable:
if there is a A and a B and a C then only one A and one B and one C is allowed
if there is a A and a C then only one A and one C is allowed
if there is only a A, then more than one A is allowed
if there is onla a B, then more than one B is allowed
just straigthforward!
look for the following input stream:
A A B C
|
first try A ^ B ^ C (leftmost production)
| this second A prohibits A^B^C and A^C
backtracking:
| try A, subrule succeeded
| try again A^B^C
| A^B^C still matches
| A^B^C subrule succeeded
....
> I agree. The wish is not strange. It is precisely what happens when a compiler
> flags a dual declaration as being incorrect.
yep, that's the key! The same is with my options in very long,
structured cfg files (think about named.cond and dhcpd.conf and includes
and all that)
>
> But it also misses the point. Its not context free and IMO not
> generallizable.
I think it's generalizeable, at least the A! | B! | C | D suggestion,
perhaps not context free. But I think that P::RD is by far no way just
a CFG ParserGenerator, it's a beast. I stumbled so many times over these
two missing features (mandatory and xor) and my "feeling" tells me, there
must be a gentler(general) solution than just doing this in action codes.
>
> But more importantly you have identified the location of the problem
> incorrectly. Its not the alternation that is the problem. Its the (s) that is
> causing the trouble. It and only it are why you can have any selection of
> items. Remove it and the language matched will be one or the other, but _not_
> both.
>
> Consider how you would vocalize what you want:
>
> I want a name and or an email, in addition to an optional phone number and fax
> number
I disagree, the problem is: I need an email and a name, optionally
a phone number and perhaps a fax number, but there should be no
order introduced for these parameters. That's the point: "No order".
When I don't wish an order in the options, then I need all
permutations:
contact: email name phone(s?) fax(s?)
contact: email phone(s?) fax(s?) name
......
contact: fax(s?) phone(s?) name email
if I wish to do this in the grammar. The only thing to do
this not with permutations is with action code, and now we are again
at the beginning of the thread :-(
Perhaps Damian can bring some light in the darkness.
Regards and THANKS for discussing!
Charly
--
Karl Gaissmaier Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED] Network Administration
