Andrew Sutton wrote:
>
> 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).
>
> otherwise, here's an alternative syntax that i'd propose (and implement)
>
> Exports ::=
> EXPORTS "(" SymbolList ")" ";" |
> empty
I guess you meant "IMPORTS" here.
> and
>
> SymbolsFromModule ::=
> "(" SymbolList ")" FROM GlobalModuleReference
I don't understand what kind of problems you have with the SymbolList.
It seems to me that your lexer doesn't provide the right lexical items to
your parser.
> that gets rid of any shift/reduce conflicts and gives the syntax a nice
> "mathematical-like" list structure.
You may be right on aesthetics, but we cannot change this in an international
standard, for it would break existing specifications.
> there are others that i've run into like the OctetStringValue/BitStringValue
> reduce/reduce conflict,
Huh? There is no conflict there. It is the role of the semantic layer of
your tool to check whether it is an OCTET STRING or a BIT STRING value.
As far as parsing is concerned, the parser builds in memory a structure
which is independent of the governing type (because a transitive closure is
needed before the semantic checker knows the type of the governor).
> but that can be worked around by making an OCTET
> STRING capable of containing a BitStringValue... no big deal there.
>
> thoughts, comments, etc?
Keep in mind that the grammar provided in the ASN.1 standard has been written
so that it makes it easier for the readers to understand the semantic rules.
Implementers need to transform the grammar into a form that is better suited
for tools.
--
Olivier DUBUISSON
france telecom R&D
_ DTL/MSV - 22307 Lannion Cedex - France
( ) tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
/ \/ --------------------------------------
\_/\ Site ASN.1 : http://asn1.elibel.tm.fr/
