> > > > At LISA, Aeleen Frisch and I will be presenting our proposal for > > cfengine 3 syntax and data model which will allow cfengine 3 to > > accomodate all these issues. If you want to read up in advance, go to > > the svn server and choose project "cfengine 3". There's a pdf in the > > svn repos with a fifty page theoretical discussion about all this. > > Hmmm. Why don't you post this on the website? Is there instructions > somewhere on how to get to the SVN repo?
I don't want everyone to see it yet!! I don't want a huge discussion about it from people who turn to the last page without reading the full thing, and then having to defend everything by email :-) > I hope that the cfengine 3 language syntax will be completely LALR(1) > specified and, so, completely parseable by YACC/LEX. I think it would make > the language easier to understand. That's missing the point. Cfengine is as parsable in lex/yacc now. The reason that some things like functions are saved until later has to do with the way it has evolved from the beginning. There is no data model that could replace functions with a compiled form, so you could not handle functions at parse time. This has nothing to do with the grammar, it has to do with the "stupid" way cfengine mixes parse-time and run-time evaluation. That needs a much deeper fix than a different parsing strategy. M _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
