Re: Overlay and actions/OLE

Martin Stein writes:
>>> (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))).
>  > ...
>> 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.
> My observation was: Whether [beg end] overlay information gets converted 
> into proper overlays depends on :something. If 'something' is 'members' 
> and other predefined stuff. Fine. For some self-defined names, 
> conversion is not done. And I cannot find which names are allowed.

Fortunately, Eric has provided the answer for that one. I completely
forgot about `semantic-tag-components'.

>>> (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.
> I have read the documentation and even looked at the generated 
> name-by.el files. I understand those stuff a bit and can use it to some 
> extend. But it feels like a blind flight. As I said, some typing as in 
> Haskell says more than lots of words. (For example: If I correctly 
> remember you can prove that from the type (a -> b) -> [a] -> [b] one can 
> (almost) deduce that this must be the map function.) Anyway, just out of 
> curiosity I will look into the source code and it should not be too 
> difficult to find out the transformation rules. In my time as a student 
> I have studied tree transducers and tree automata, so this is 
> interesting in itself to me.

I remember I pretty much hacked my way through this through trial and
error. If you find proper transformation rules for these things, please
share them here, so that we can put them in the documentation. It might
also be that you'd be more happy with Wisent, which is Semantic's LALR
parser (pretty much a Bison port). The grammar shouldn't be hard to port
to it. I simply didn't use it because I find bottom-up parsing
absolutely horrible to debug, but you as a mathematician should have no
problem with that. ;-)

>> 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.
> I can appreciate your hacks. They helped a lot to getting started. I 
> have already done some stuff, such as:

[...]

That sounds great!

> However, before I can start to use it, I need good preprocessor 
> handling. I should be able to reuse the code from the c.el file.

Yeah well, I ducked that one. The preprocessor is handled as a special
lexer (see lex-spp.el) and isn't directly tied to C/C++, so it should be
reusable for Fortran. Be warned though that this is pretty hairy and has
been an endless source of frustrations when dealing with C/C++, since in
real life, the preprocessor runs before the lexer. I always wanted to
write a proper C preprocessor in Emacs Lisp to handle this cleanly, but
for now I'm rather looking into writing a GCC plugin instead to pretty
much replace our existing parser, which will also get rid of "the
preprocessor problem".

>> 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).
> Ah, I already assumed that the f90.by/f90.el is already GNUFSFed. 
> Copyrighting it to FSF is not a problem, as I code this privately at home.

Well, they're not yet FSF copyrighted, but they will have to be when
they get merged to Emacs. Unfortunately, assigning copyright to the FSF
involves some actually signed papers and takes a few weeks. I'll send
you the instructions off-list.

-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