Hi,
Thanks for all those cues. I am using a glr parser so if there is any
ambiguity, I just give precedence to one of them and later resolve them at
later stage based on the type (I guess that's the method b that u had
mentioned). But the problem that I faced is that the grammar is in such a
manner that the ambiguity is within the same context not like ambiguity b/w
SequenceValue/ObjectIdentifierValue or somethin like that but within the
DefinedSyntax itself. The ambiguity is within defined syntax, which is
basically a sequence of prdn 'Setting' and comma. So when the parser sees a
Type followed by lets say a SequenceOfValue, it is not able to determine if
its a Type followed by a value or to consider it as a parameterized type. I
am able to resolve issues b/w 2 different entities like SequenceValue vs
Object Identfier value etc. The problem I am facing is the conflict is
within the DefinedSyntax itself, in case any of u faced this problem and
have a soln w.r.t the grammar or if any one else is able to give suggestions
in this respect do advise. Thanking you. Bye.
Regds
Ram
----- Original Message -----
From: "Geoff Elgey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 28, 2003 3:51 AM
Subject: Re: [ASN.1] DefinedSyntax
> G'day,
>
> Ramaswamy wrote:
> > I am using bison for parsing the ASN.1 spec file. The defined syntax
> > leads to ambiguous parsings. consider the code fragment below
> >
> > myobject MYCLASS ::= { Integer { 1, 2 } }
>
> It gets worse. Consider the following:
>
> v1 T1 ::= {a 1, b 2}
>
> The right-hand side is syntactically equivalent to a SEQUENCE value,
> and to a DefinedSyntax value.
>
> In fact, a DefinedSyntax value may be syntactically equivalent to a
> SequenceValue/SetValue, or a SequenceOfValue/SetOfValue, or an
> ObjectIdentifierValue, or an argument list (there's probably a few
> more equivalences, but that's off the top of my head).
>
> And any argument list is syntactically equivalent to a DefaultSyntax
> value: {T{1,2}} may be a valid sentence for the default syntax {&Type
> &value}, and for the default syntax {&Type}, and for the defined
> syntax {T &value}.
>
> > How can I modify the grammar to accept the input in either one of
> > its for without the context info??
>
> Short answer: you cannot. In some cases, an ASN.1 value cannot be
> determined without full knowledge of the associated ASN.1 type. For
> example, what is "{a 1}" without any further context? Is at an
> ObjectIdentifierValue? Is it a SequenceValue? Or is it a
> DefinedSyntaxValue? Without the type, it's just a list of lexical
> tokens, nothing more.
>
> There are two methods of dealing with this ambiguity:
>
> (a) When parsing, gather up any token sequence of the form "{...}",
> making sure that nested "{...}" sentences are handled. This will at
> least make sure that the input is *almost* well-formed. When the type
> information is known, the token sequence can be parsed using the
> appropriate production.
>
> (b) If a token "{" appears when parsing a Value, then mark the current
> point in the parse. Try parsing each Value production alternative that
> may begin with a "{", rewinding back to the starting point afterwards.
> If only one production succeeded, then that's your candidate. If
> more than one productions succeeded, then bundle them up into an
> "AmbiguousValue" that can be resolved when the full type information
> is known.
>
> Method (a) allows for easy parsing, but will not catch invalid
> sentences such as "{1 SEQUENCE , , }" until type information is known.
> If you want to check if a some ASN.1 is syntactically correct (and
> without performing any linking/semantic analysis), then this method is
> not adequate.
>
> Method (b) will guarantee that the ASN.1 input is syntactically valid
> after the parse. However, there may be a lot of backtracking. Also, by
> parsiung the same sentence more than once, many syntax errors may be
> generated, and it is not generally determinable which errors should be
> discarded (if any).
>
> The previous ASN.1 compiler I developed used method (a), but another
> one I'm messing about with now uses method (b). This is because I
> wanted to split the compiler into two parts: one part that parses the
> input and checks that it is syntactically valid, and one part that
> takes this valid input and performs the necessary semantic analysis.
> If you're not interested in syntactic validity, then method (a) is
> sufficient.
>
> [I'm thinking about freely releasing the syntax parser soon, with the
> semantic analyser to follow later. I'm just in the middle of writing a
> grammar recognizer that will generate the necessary syntactic test
> cases. This would, I hope, be part of the asn1.org test suite that was
> once mooted]
>
> Cheers,
> Geoff
>
>
>
>
>
