Re: Grammars, Ambiguous, ASN.1

G'day,


> Bear in mind that the ASN.1 grammar is ambiguous and cannot be parsed
> completely with LALR(1). It needs lexical tie-ins for disambiguation.


I'm writing an ASN.1 compiler at the moment, actually. The grammar is
horrible - how was it ever designed? I've had to do all sorts of evil
tricks to parse correctly.


> Also, macros are horrendously hard, if not downright impossible, to
> implement with Yacc and friends since macros can change the grammar
> midstream.


This relates to the question I was going to ask - what is the best way
of parsing a user-defined grammar on the fly?


In X.681, a CLASS type may be given its own syntax, as follows:


SyntaxList ::= "{" Productions "}" .
Productions ::= { Production } .
Production ::= "[" Productions "]"
                              | word
                              | ","
                              | PrimitiveFieldName .


where 'word' is an sequence of upperclass letters (except for some
special cases), and a 'PrimitiveFieldName' is an '&' followed by some
identifers and periods.


So the text to be parsed could (syntactically) look like this:


  T1 ::= CLASS {
        &ArgumentType INTEGER,
        &ResultType INTEGER,
    } WITH SYNTAX {
            ARGUMENT &ArgumentType
            RESULT DEFINED TO BE &ResultType
        [ ARGUMENT &ArgumentType
            RESULT DEFINED AS &ResultType ]
        [ ARGUMENT &ArgumentType
            RESULT DEFINED BY &ResultType ]
            ARGUMENT &ArgumentType
            RESULT DEFINED &ResultType
    }


I'm wondering - what is the best way to parse such productions? I'm
thinking that a bottom-up parser would be the best option.


Of course, a parser would have to be generated automatically for each
syntax list in the source text, and from within the main parser itself.


Any ideas/suggestions?


Cheers,
Geoff

Return to the comp.compilers page.
Search the comp.compilers archives again.