Re: [ASN.1] asn specification
I am not a BNF expert, so just a layman's question: Can the problems you are having be mended by simply changing the BNF in the ASN.1, or would a mend affect the actual notation being defined? If the former, do you have (or could you produce) a complete set of proposed changes to the BNF that would correct the problem? If the latter, I am afraid you are about twenty years too late! John L Patrick Henry wrote: On Thu, 18 October 2001, Olivier Dubuisson wrote: 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. Not exactly. The problem is that the 'valuereference' lexeme is used ambiguously in two contexts, both the SymbolList production and the DefinedValue production (which is part of AssignedIdentifier and hence GlobalModuleReference). There is no way to resolve the conflict in a straight recursive descent parser without resorting to the kind of fishing that Paul described in a prior message, q.v. As for bottom-up parsing, my compliments to Christian for his brilliant display of LALR(1) grammar transformations; but I have serious doubts about the sanity of such an approach. Any comments? To what extent has lex/yacc been used in ASN.1 compiler design? Regards, Patrick Henry Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com -- Prof John Larmouth Larmouth TPDS Ltd (Training and Protocol Development Services) 1 Blueberry Road Bowdon [EMAIL PROTECTED] Cheshire WA14 3LSTel: +44 161 928 1605 England Fax: +44 161 928 8069
Re: [ASN.1] asn specification
We have dealt with this problem and others like it using the infamous lex tie-in that is prevalent in the SNACC code. That is to say swallow the whole thing up and deal with it on the back end essentially emulating multi-token look aheads. It isn't pretty, but it works. Ed Day Principal Engineer Objective Systems, Inc. [EMAIL PROTECTED] (484) 875-3020 (main) (610) 608-4930 (mobile) (610) 321-0361 (fax) (877) 307-6855 (toll-free) - Original Message - From: Patrick Henry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, October 25, 2001 12:01 AM Subject: Re: [ASN.1] asn specification On Thu, 18 October 2001, Olivier Dubuisson wrote: 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. Not exactly. The problem is that the 'valuereference' lexeme is used ambiguously in two contexts, both the SymbolList production and the DefinedValue production (which is part of AssignedIdentifier and hence GlobalModuleReference). There is no way to resolve the conflict in a straight recursive descent parser without resorting to the kind of fishing that Paul described in a prior message, q.v. As for bottom-up parsing, my compliments to Christian for his brilliant display of LALR(1) grammar transformations; but I have serious doubts about the sanity of such an approach. Any comments? To what extent has lex/yacc been used in ASN.1 compiler design? Regards, Patrick Henry Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com
Re: [ASN.1] asn specification
On Thu, 25 Oct 2001, Ed Day wrote: We have dealt with this problem and others like it using the infamous lex tie-in that is prevalent in the SNACC code. That is to say swallow the whole thing up and deal with it on the back end essentially emulating multi-token look aheads. It isn't pretty, but it works. Agreed. Any number of tools cope fine with the BNF as it is, I don't see the need for a change. Remember that ASN.1 is not LR(1). Bancroft
Re: [ASN.1] asn specification
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 RD _ 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/
