I think the answer is "it is inherent in DFDL". Backtracking is not evil. It is perhaps the most straightforward way to handle many kinds of grammar ambiguity.
It is inherent in dfdl that dfdl has to accomodate the grammar of the data format as it is expressed in dfdl. We don't get to decide that the data format is too complicated and require it to be expressed more simply so as to allow a specific kind of efficient parser. The advice in Bennett's book must be talking about both programming language design and the parsing and compiling of that language, together, as one problem. In that scenario one can change the programming language syntax (i.e., the grammar, say to require a semicolon at the end of every statement) to meet requirements (like "no backtracking") at the expense of making the syntax harder to deal with for people (who hate having to put in the semicolons). Ideas like converting LR to LALR(1) grammars, clever parsing algorithms for specific kinds of grammars, etc. None of that is relevant to dfdl because we dont have any control of the grammar. I think this advice in this and many other compiler books is only selectively relevant to dfdl implementations. If you allow the language grammar to be constrained by the parser technology to be used, all sorts of parser theory applies which is just not applicable to a universal parser that parses based on a DFDL description. On Tue, Apr 19, 2022, 6:27 AM Roger L Costello <coste...@mitre.org> wrote: > Hi Folks, > > I am reading a compiler book [1] and it says this: > > "An important practical criterion is that a parser should not backtrack. > At all stages it should operate deterministically. A number of authors have > described backtracking parsers, but those are rarely used in practice. It > is difficult to undo semantic actions carried out by the parser as is > necessary if it has to backtrack." > > Why does Daffodil do backtracking? Is it due to an inherent limitation of > the DFDL language or is it due to the way Daffodil is implemented? > > /Roger > > > [1] Introduction to Compiling Techniques by J.R. Bennett, see bottom of > page 80 > Julio
