Re: Overlay and actions/OLE

David Engster <[email protected]>
Newsgroups gmane.emacs.cedet
Message-ID <[email protected]>
Hi Martin,

sorry for the late reply.

Martin Stein writes:
> There are two things which eludes me. Any help is greatly appreciated.
>
> (1) Overlay information:
>
>    (a) Exactly for which actions does the parser add overlay information 
> to a tag in raw [lower upper] format? (I have created tags, passed them 
> up, put them into a list like :something (tag) and lost the overlay 
> information.)
>
>    (b) How is [lower upper] converted to the <#overlay ... in file.f90> 
> format? It is clear that this happens after the semantic-expand-tag 
> function. It is also clear that the top level tag gets its overlay 
> information converted. Moreover, it seems that tags collected within 
> certain attributes are converted as well (e.g. conversion is done for 
> tags collected by (TAG ... :members (EXPANDFULL $x rule)), but not for 
> (TAG ... :membersxyz (EXPANDFULL $x rule))).

I remember how I battled with the exact same things. Unfortunately, I've
forgotten most of it... so take the following with a grain of salt, and
hopefully Eric chimes in.

So let's start at the bottom: The Bovine parser gets a stream from the
lexer, containing the tokens. Each token contains a start and end point
in the buffer, which can be accessed by helper functions like
semantic-lex-token-start/end/bounds. The Bovine parser now tries to
match the tokens against the rules. If one matches, it calls the
optional lambda expression (see the 'funcall' in
semantic-bovinate-stream). The optional lambda expression is created by
the `semantic-lambda' macro, which will append the start and end of the
matched tokens. This is what in the end should turn up as the raw [lower
upper] format from the parser.

The overlays are then generated by `semantic--tag-link-to-buffer'. This
is necessary so that you can deduce the buffer this tag belongs to, as
well as the filename.

> (2) Actions in rules: I have a good background in Haskell, and I would 
> love to see the typing for those (TAG ...) actions. I just do not 
> understand for example when to use ( ) versus ( nil ), or ( ,$1 ) versus 
> ( $1 ). The documentation does not help me much there. I guess I would 
> need to look at the by -> by.el conversion rules? As a mathematician any 
> formal transformation rules (preferably typed) could help a lot I think.

As far as I can remember, '( )' and '( nil )' should be the
same. Regarding '( ,$1 )' and '( $1 )', this should only matter when $1
is a list. When you use ,$1, this list gets "spliced" into the arguments
for the lambda expression, meaning it gets "flattened". I think.

Really, the best way is to simply debug into your actions and look at
the arguments...

Anyway, I don't do Fortran90 anymore, but I would be thrilled if someone
continued with the parser. I freely admit the parser is a bit weird,
since most work is actually done in the lexer. But Fortran is really
ugly to parse because of all this history with the "specification part"
and "execution part" and such.

If you plan to submit patches, please be aware that you'd have to assign
copyright to the FSF, since CEDET is part of Emacs (the Fortran parser
isn't at the moment, but if it improves further, I think it should be
merged to Emacs).

-David

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.