Re: Syntax diagram driven parser

"Sebastian Moleski" <sebmol@gmx.net> schreibt:
>Since Delphi's grammar is indeed representable with EBNF, this
>shouldn't be much of a problem.


Just a question: how would you represent in EBNF, that certain
procedures (Write...) accept arguments of the form
"expr:prec:decimals", in contrast to all other procedures? Of course
that's possible, but will bloat the EBNF syntax. With all such special
cases an EBNF syntax will be many times larger than the form, used by
Borland to describe the OPL syntax.


But unfortunately the Delphi documentation neither describes the
syntax description language, nor is the description of the OPL grammar
itself correct or complete. Therefore I've spent much time with
testing what the D4 compiler actually accepts, and built my own OPL
grammar accordingly. There exist so many subtle differences, which
would require to replicate and slightly modify large parts of an EBNF
grammar, so that it's almost impossible to verify, that such a grammar
really correctly covers all combinations of different contexts.
Consequently I couldn't find any published EBNF grammar for OPL, which
really represents the Delphi4 OPL grammar.


The resulting grammar uses my own extensions to BNF, with context
variables. These variables are set accordingly, whenever a special
context (class, record, case...) is entered, and are used to determine
the actual set of productions in other parts of the grammar. Perhaps
Yacc would accept such variables, otherwise it might be an interesting
project to construct an preprocessor, which would convert that grammar
into EBNF. But I never finished that grammar, instead I started to
implement an according parser manually, and extended it by trial and
error, until it accepted all the VCL units and also my own test
units. Hereby I gave up to create an really perfect parser, instead
the parser accepts slightly more than the compiler would accept;
otherwise it had been necessary to create a different parser (and
grammar) for every Delphi version. OPL is, what a specific compiler
accepts :-(




In the OPL syntax also cases exist, where the kind of a symbol is
important, whether it represents e.g. a constant value, a module name
etc. I'm not very familiar with theory of grammars, but I doubt that
a parser would be able to determine the kind of a symbol, which is
imported from another module, and thus *cannot* know which syntax rule
to use.


Perhaps such details are of no concern with a grammar, where you
simply can use subclasses of symbols, and delegate it to the scanner
to return the appropriate tokens; but I think that such a grammar is
of little use, when you want to create an parser from it.


DoDi

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