Re: Overlay and actions/OLE

Hi David,

 > sorry for the late reply.
Well, it's Christmas time...

>> 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))).
 > ...
> 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.

>> (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.

> Really, the best way is to simply debug into your actions and look at
> the arguments...
Yeah I know, this helps a lot.

> 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:
(1) Better regex for names (e.g. underlines are not allowed in the 
current version)
(2) Improvements for continuation lines (still not completely done, and 
will never be completely done, as Fortran allows weird code like

      call my_fu&
!  some comment
         &nction(arg,&
        sndarg)

(3) Moved work from the lexer/expand-tag to the parser, e.g. the lexer 
generates 'MODULE semantic-list CONTAINS semantic-list', and then uses 
rules to extract USE and PUBLIC information, instead of doing this work 
by hand in the expand-tag function.

(4) Added the result keyword to functions statements.

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.

> 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.

Merry Christmas,
Martin

PS: Unfortunately, the first version of the email accidentially went to 
the private mailbox of David instead of the mailing list.

------------------------------------------------------------------------------
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