Re: [Cfengine-develop] Development plan / meeting

[Luke A. Kanies]

On Mon, 3 Mar 2003, Andrew Stribblehill wrote:

> Quoting Mark Burgess <address@hidden> (2003-03-03 11:55:08 GMT):
> >
> > Quoting Bas:
> > >  - If the parser/lexer is rewritten. We can remove a lot of code
> > >    from cfengine. Like checking if we suppply the right keywords
> > >    with the right values, eg: Now there are checks everywhere
> > >    if we supplied a integer to a keyword. I personnaly think
> > >    that this will make the cfengine source more readable,
> > >    extendable and maintenable.
> > >
> >
> > I suggest that, along side the current cfengine development,
> > someone prototypes a "mockup" new parser, showing the
> > structure and grammar.
> >
> > That can be incorporated at a later stage. It is such an important
> > thing to get right that we need a "toy model" before we can
> > do anything "for real".

While I generally like this idea, from what I can tell (from my minimal
experience with writing parsers) changing the parser in cfengine would
require significant rewriting of the core cfengine code.  Thus, any
example parser/lexer combination would be largely nonfunctional; it would
have to be accepted largely on its ability to successfully parse, without
having the ability to build data structures.

I could be wrong about this, but this is how it looks to me.  I'd love to
find out I'm wrong. :)

> Forgive me if I get my terminology wrong -- I'm another of those
> former physicists and never did any formal compiler work...
>
> What are the types that we need to handle? Obviously, strings and
> integers. Should permissions be a basic type? How about booleans? IP
> ranges? Enums?
>
> At present, we're parsing a lot as if it's a string, then at
> work-time, checking to see if it makes sense. With some well-chosen
> basic types we can move loads of checking to the parse stage and
> simplify code.

Hmmm.  While I applaud the idea of simplifying the parsing code, I'm not
sure how good an idea this is.  If you want your parser always identifying
data types, then you essentially have to have strongly typed variables
which can't have their value changed to another type, or you have to have
the parser do all variable interpolation, enabling it to check data
correctness at parse time.

Adding strong typing (disallowing a variable to store data of different
types) makes things more explicit, but I personally think it also makes
a language for more annoying to use.  I'd really prefer not to go this
route.

Without strong typing, the parser has to interpolate variables completely,
in order to verify that a variable contains the correct data.  If the
parser is responsible for variable interpolation, then it's also going to
have to be responsible for all the work that sets the value of variables;
in other words, it will have to perform the actual execution of the code.

If this is what people want, then that's fine, but it should be understood
from the beginning that this will be the result.

Personally, I would prefer to keep the basic data types we have now (what,
strings and booleans), and add tests for higher-lever data types:  IsIP(),
IsHostname(), etc.  This is more flexible, more easily extensible, and
far less coupled to the parser, which I think is a good thing.  Just make
those functions available to your modules, too, once an inline module
interface is written.

Luke

-- 
"They called me mad, and I called them mad, and damn them, they
outvoted me."
 -- Nathaniel Lee on being consigned to a mental institution,
circa 17th c.