Forwarded because Christian is not subscribed to this list with his Korean
email address.
Thanks to him for this detailed answer.
-------- Original Message --------
Subject: Re: [Fwd: [ASN.1] asn specification]
Date: Tue, 23 Oct 2001 09:07:50 +0900
From: Christian Rinderknecht <[EMAIL PROTECTED]>
Organization: Information and Communications University (Daejeon, Korea)
To: Andrew Sutton <[EMAIL PROTECTED]>
CC: "DUBUISSON Olivier FTRD/DTL"
<[EMAIL PROTECTED]>,[EMAIL PROTECTED],[EMAIL PROTECTED]
Hello Andrew,
> -------- Original Message --------
> Subject: [ASN.1] asn specification
> Date: Wed, 17 Oct 2001 16:15:33 -0500
> From: Andrew Sutton <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Organization: Software Emgineering Pros.
> To: [EMAIL PROTECTED]
>
> hi,
>
> i've gotten bored so i've been working on an ASN.1 compiler based on the 97
> specifications. actually, it was going pretty well until i realized that i
> had mistyped the SymbolsImported productions. anyway, i ran into a problem
> and had some feedback or could propose an alternative syntax...
>
> it seems that the way that the SymbolsFromModuleList is constructed, you can
> run into a number of shift/reduce conflicts. if AssignedIdentifier attached
> to the GlobalModuleReference is a DefinedValue it conflicts with the first
> Symbol in the next SymbolList for multiple imports - if the first symbol is
> an abstract value (as opposed to type). if i'm just looking at this all
> wrong, let me know (like if its changed in a future version).
You can proceed as follows.
The initial rules are:
symbolsImported:
symbolsFromModuleList { }
| /* empty */ { }
;
symbolsFromModuleList:
symbolsFromModule { }
| symbolsFromModuleList symbolsFromModule { }
;
symbolsFromModule:
symbolList FROM globalModuleReference { }
;
globalModuleReference:
Modulereference assignedIdentifier { }
;
assignedIdentifier:
objectIdentifierValue { }
| definedValue { }
| /* empty */ { }
;
After lifting the recursivity of rule [symbolsFromModuleList] into
[symbolsImported], and expanding rules [globalModuleReference] and
[symbolsFromModule], you get the following equivalent definition for
[symbolsImported]:
symbolsImported:
symbolList FROM Modulereference assignedIdentifier symbolsImported {
}
| /* empty */ {
}
;
Now you create a new suffix rule:
symbolsImported:
symbolList FROM Modulereference newRule { }
| /* empty */
;
newRule:
assignedIdentifier symbolsImported { }
;
And you expand [assignedIdentifier] in it:
newRule:
objectIdentifierValue symbolsImported { }
| definedValue symbolsImported { }
| symbolsImported { }
;
Now, YACC is happy.
> otherwise, here's an alternative syntax that i'd propose (and implement)
>
> Exports ::=
> EXPORTS "(" SymbolList ")" ";" |
> empty
>
> and
>
> SymbolsFromModule ::=
> "(" SymbolList ")" FROM GlobalModuleReference
>
> that gets rid of any shift/reduce conflicts and gives the syntax a nice
> "mathematical-like" list structure.
Unfortunately it is impossible to change the abstract syntax, because it
would break all the existing specs...
> there are others that i've run into like the OctetStringValue/BitStringValue
> reduce/reduce conflict, but that can be worked around by making an OCTET
> STRING capable of containing a BitStringValue... no big deal there.
>
> thoughts, comments, etc?
The whole ASN.1 grammar has hundreds of shift/reduce and reduce/reduce
conflicts...
Best regards,
--
Christian
------------------------------------------------------------------------
Christian Rinderknecht Phone +82 42 866 6147
Network Architecture Laboratory Fax +82 42 866 6154
Information and Communications University WWW http://nalab.icu.ac.kr
58-4 Hwaam-dong, Yuseong-gu, Daejeon, e-mail [EMAIL PROTECTED]
305-732, South Korea
