Hi,
>>> DaveS <davls@...> seems to think that:
>Hello, I'm trying to setup semantic for a language but I'm relatively
>new to everything so I was hoping someone could help me. I'm using the
>wisent parser and a grammar file that I started by shamelessly copying
>from the java grammar wherever I could. (using cedet1.0b1 btw)
>
>I need to setup a rule for a const declaration: const int a=1, b=3, c=4;
>So far I have
This is a compound statement. It shows up in a grammar near the top
like this (in the way I was originally taught about grammars.)
statement: variable
| function
| etc
;
For tagging purposes, your statement wants to be represented as three
tags covering an overlapping area with the same type, different
bit-fields or constness, or whatever.
>const_declaration
> : attrs_opt nonclass_modifiers_opt CONST type const_declarators
> (mapcar '(lambda (e)
> (EXPANDTAG
> (VARIABLE-TAG (car e) $4 (cdr e) 'const t 'typemodifiers $2)))
> $5)
> ;
>
>const_declarators
> : const_declarators COMMA const_declarator
> (cons $3 $1)
> | const_declarator
> (list $1)
> ;
>
>const_declarator
> : IDENTIFIER EQ constant_expression
> (cons $1 $region3)
> ;
>
>I know the const_declaration rule is bogus. I was hoping there was some
>idiom for generating multiple tags from a single rule.
>
>I noticed that the java grammar has a rule
>field_declaration
> : modifiers_opt type variable_declarators SEMICOLON
> (EXPANDTAG
> (VARIABLE-TAG $3 $2 nil 'typemodifiers $1)
> )
> ;
>wouldn't this create a single variable tag from all the declarators?
The VARIABLE-TAG macro creates a single variable where $3 returns some
information about each variable in the compound statement. I'm not
completely sure of David's implementation, but what the EXPANDTAG
macro then does is break up the compound tag into the individual tags
that conforms to the semantic tag format.
>I'm also a bit confused on the use of EXPANDFULL. Is there a performance
>advantage to using this macro instead of writing bison style rules? If
>so I'll have to make an effort to understand how it works.
>Many thanx.
Emacs Lisp is not an ideal language for this purpose. While Lisp,
and the Emacs derivation itself is certainly great, there are
distinct speed issues. We can hide many of those speed problems in
the lexer by using Emacs's built in ability to skip over balanced
sets of parenthetical pairs. (identified by BLOCK lexical analyzers.)
This is fast, but there is often good stuff in those parentheses.
EXPANDFULL allows you to use semantic's robust iterative parsing
algorithm in parenthetic blocks.
So, the advantages are:
* Speed in writing grammars for and parsing code blocks not needed for
tag generation. (code blocks)
* Robust parsing of dynamic declarative blocks. (class bodies, etc)
Good Luck
Eric
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|