Re-designing the config parsers

Francis Dupont fdupont at
Fri Sep 12 19:54:54 UTC 2014

Marcin Siodelski writes:
> On 12/09/14 12:44, Francis Dupont wrote:
> > Tomek Mrugalski writes:
> >> On 11.09.2014 18:01, Francis Dupont wrote:
> >>> Marcin Siodelski writes:
> >>>> I should also explain that we discussed with Tomek a use of Bison
> >>>> framework ( in Kea.
> >>>
> >>> => I heavily used bison (and other LALR(1) parsers) in the past...
> >>> BTW if you want to provide a parser style config, IMHO the best
> >>> available is JunOS from Juniper (far better than the Cisco config).
> >> No, we don't want to change the format. It will stay as it is.
> >> The plan is to refactor/redo the code that parses that input.
> > 
> > => so you have bison and equivalent, and for hand written parsers
> > top down vs bottom up.
> > 
> So, a statetement about bottom-up vs top-down

=> bison is LALR(1) so bottom-up (BTW my statement about bottom-up vs
top-down was for hand written parsers, so not for bison & co where
the used mechanism is fixed, at the opposite to write a grammar is
far lighter than to write a full parser).

> doesn't tell me much if I can make Bison parse the elements of the
> configuration in a desired order.

=> all parsers I know are left to right. IMHO what do you want is not
a parser (aka syntax analyser).

> So for example, the simplified configuration file:
> ----
> dhcp-option-fqdn = ""
> dhcp-option-fqdn has type FQDN
> ----
> defines a value for the new option called "dhcp-option-fqdn" in the
> first line and the option format in the second line.

=> the line as a basic construct is not the best...

> So, I want the parser to read the format of the option (second line)
> before reading the option data "" and I want to report a
> parser error if the "" is not a legal fqdn.

=> first I recommend against context sensistive ideas, second it is
a typing problem.

> Is this configurable?

=> of course it is not.


Francis Dupont <fdupont at isc.

PS: you have an I/O system which gives the input, a lexical analyser
(aka scanner or lexer) which gives individual tokens, a syntax
analyser (aka parser) which builds a tree representing the input. Next
you have some passes on the tree, the most common and usually at the
beginning is the typing.

More information about the kea-dev mailing list