Re-designing the config parsers
Francis Dupont
fdupont at isc.org
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 (http://www.gnu.org/software/bison/) 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 = "foo.marcin.com"
> 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 "foo.marcin.com" and I want to report a
> parser error if the "foo.marcin.com" 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.
Regards
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