On 09/24/2012 08:00 AM, kototama kototama wrote:
> Hi,
>
> I have managed to write a minimal grammar and generates a first tag
> (yeah!). Now I have some questions about tags generation:
>
> - what is the difference between EXPAND, EXPANDTAG and EXPANDFULL?
Hi Kototama,
These are explained in the semantic language authors guide. In a
nutshell, however:
EXPAND takes a complex lexical element (usually a parsed list) and
recurses into that list. You pass in the lexical token (like $2 for the
second match in some rule) and the name of the rule you want to start
parsing with. This is a one-shot deal. Whatever is created in that
rule is passed back out into the current code of the rule calling EXPAND.
EXPANDFULL is the same, except it is iterative, meaning that the passed
in rule is parsed against over and over until there are no more matches.
This is useful for argument lists to functions and the like.
EXPANDTAG is different. All tags you create in you grammar with a
VARIABLE-TAG or other constructor is in a 'raw' form that needs to be
cooked up to be useful. EXPANDTAG is used in grammars where one
top-level rule might return a bunch of tags. For example, if you use
EXPAND on a list, and that list returns a bunch of tags, then those tags
probably need to be EXPANDTAGed. If you use EXPANDFULL on your list,
and each iteration finds only one tag, then the system will EXPANDTAG
automatically, so you won't need to call it. I recommend always using
iterative parsers so you don't need to worry about this.
> - how can I used VARIABLE-TAG / PACKAGE-TAG to specify the package in
> which a variable is defined?
Your parser should "tell it like it is" in the code, and not attempt to
draw additional conclusions. Use overload functions applied to the
parsed buffer to make additional assumptions.
For example, in C++ you might have:
int myclass::mymethod(int a) { };
which should parse as a function whose :parent is myclass, but:
class myclass {
int mymethod(int a);
}
then mymethod should not have a :parent, but instead be a member of the
:children of myclass.
so in Java, code like:
package mypackage;
class myclass {
};
would just be two tags independent of eachother. After the file is
parsed, the semantic system will associated the two simply because they
exist in the same file.
> - is it possible to generate tags for function calls, parameters
> usages and variables usages so that they can later be searched?
All the parsers in Semantic ignores parsing code. Parsing is
time-consuming, and complex. It is much simpler to stick to
declarations, and allow clever Emacs lexical capabilities to convert
code blocks into big blobs of text we just call :code, but otherwise ignore.
There is no reason Semantic parsers could not parse all the code. It is
possible, but there are no tools to deal with the output. It would be
an interesting direction to go, and I can think of neat things to do
with it, but it is a new area.
If you want to search that stuff, you can get a tool like GNU Global,
IDUtils, or cscope, and use that to parse your code, then use the
integration with semantic-symref to navigate or query your code.
Good Luck
Eric
|