Re: asking for advice for changing the cfengine.el progmode to support CFEngine 3.x

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 22 Jun 2011 13:44:02 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I tried, but I can't examine the parser state at a buffer point or do
>> anything else to debug the SMIE grammar.  How do you do it?

SM> I use C-M-f and C-M-b (SMIE hooks into these commands so that it jumps
SM> not only over (..) but also pays attention to the defined grammar), as
SM> well as looking at smie-grammar.

Yeesh...  I'm reading the "Parsing Techniques" book you referenced, but
understanding the SMIE grammar table will take me a while.

>> I'm also surprised that Emacs doesn't have a decent LALR parser outside
>> Semantic, and Semantic itself is poorly documented as far as writing new
>> language support.

SM> LALR only works forward, so it requires parsing from the beginning of
SM> the file, which basically forces you to use a cache or something
SM> like that.  OPG on the other hand are bidirectional.

...so you are saying OPG are the way you'd like to go in general?  I
thought syntax tables took care of most of the parsing and state
caching, but honestly I just don't know that area of Emacs well at all.

...
SM>   I don't understand enough of cfengine's grammar to know how best to
SM>   handle this problem (what makes "$(init) restart" into something
SM>   special, is it because it's a string, is it the \n that follows it,
SM>   ...?).

Rather than try to explain the grammar, I'll write it out.  That way the
terminology is clearer; I should have started there instead of giving
you ad-hoc examples.  Sorry about that.  I hope the explanation is
sufficient to clear things up.

There's a lexer and a parser for cfengine3 here:

http://source.cfengine.com/svn/core/trunk/src/cf3parse.y
http://source.cfengine.com/svn/core/trunk/src/cf3lex.l.in

I don't see a formal BNF grammar but the parser is pretty
understandable, standard top-down.  I rewrote it in a condensed form
from the .y file, hoping to make it easier to understand.  I think it's
pretty hard to parse with an OPG, since it's very context-sensitive.

Ted

specification: blocks
blocks: block | blocks block;
block:                 bundle typeid blockid bundlebody
                     | bundle typeid blockid usearglist bundlebody
                     | body typeid blockid bodybody
                     | body typeid blockid usearglist bodybody;

typeid: id
blockid: id
usearglist: '(' aitems ')';
aitems: aitem | aitem ',' aitems |;
aitem: id

bundlebody: '{' statements '}'
statements: statement | statements statement;
statement: category | classpromises;

bodybody: '{' bodyattribs '}'
bodyattribs: bodyattrib | bodyattribs bodyattrib;
bodyattrib: class | selections;
selections: selection | selections selection;
selection: id ASSIGN rval ';' ;

classpromises: classpromise | classpromises classpromise;
classpromise: class | promises;
promises: promise | promises promise;
category: CATEGORY
promise: promiser ARROW rval constraints ';' | promiser constraints ';';
constraints: constraint | constraints ',' constraint |;
constraint: id ASSIGN rval;
class: CLASS
id: ID
rval: ID | QSTRING | NAKEDVAR | list | usefunction
list: '{' litems '}' ;
litems: litem | litem ',' litems |;
litem: ID | QSTRING | NAKEDVAR | list | usefunction

functionid: ID | NAKEDVAR
promiser: QSTRING
usefunction: functionid givearglist
givearglist: '(' gaitems ')'
gaitems: gaitem | gaitems ',' gaitem |;
gaitem: ID | QSTRING | NAKEDVAR | list | usefunction

# from lexer:

bundle: "bundle"
body: "body"
COMMENT    #[^\n]*
NAKEDVAR   [$@][(][a-zA-Z0-9_\200-\377.]+[)]|[$@][{][a-zA-Z0-9_\200-\377.]+[}]
ID: [a-zA-Z0-9_\200-\377]+
ASSIGN: "=>"
ARROW: "->"
QSTRING: \"((\\\")|[^"])*\"|\'((\\\')|[^'])*\'|`[^`]*`
CLASS: [.|&!()a-zA-Z0-9_\200-\377]+::
CATEGORY: [a-zA-Z_]+: