Re: semantic-analyze-current-context for fortran functions and subroutine

Hi Eric,

Eric Ludlam wrote:
> Gesendet: Dienstag, 10. Februar 2015 um 03:21 Uhr
> Von: "Eric Ludlam" <[email protected]>
> An: "Martin Stein" <[email protected]>, [email protected]
> Betreff: Re: [CEDET-devel] semantic-analyze-current-context for fortran functions and subroutine
>
> On 02/05/2015 05:13 PM, Martin Stein wrote:
> > Just to try it out I added a new class
> > semantic-analyze-context-subroutine with methods for type-constraint and
> > show and overloaded semantic-analyze-current-context (well mostly I
> > copied the default routine and added a cond branch for the subroutine).
> > Works fine, except for having an almost complete copy of this analyze beast.
> 
> Huh, I think we can find a better way to integrate in new kinds of 
> contexts that overloading all of semantic-analyze-current-context.  Not 
> sure what at the moment though.

For the moment I will just overload those functions and refactor them into small blocks. There are just
too many subtle differences. (It took much time to think up ways to make it fitting, only
to finally realise that some small part still does not work. Nevertheless, this helped a lot to
get the tag structure pretty close to what C/C++ produces.)
Eventually I hope that this helps to identify common blocks of code which can be merged back
into the default routines. That should not be too difficult.

> > BTW-2: I also saw that eventually I will need to overload some more
> > functions relying on regexp matching or forward-sexp (e.g.
> > semantic-ctxt-current-symbol), otherwise those nasty fortran
> > continuation lines are not dealt with properly (giving a wrong context...).
> 
> Indeed.  Hopefully not too many though.  The default versions of things 
> like `semantic-up-context'  and the like tries to rely on functions like 
> `up-list' so if fortran supports those you'll be ok.
> 
> For the current-symbol, we could update elements related to looking at 
> the type relation separator and see if we can enable a language to 
> extend it to include looking at continuation symbols.

That will not work, continuation lines are too complex, here is an example of a variable declaration:

  integer :: my_var

can also be spread like this

  integer ::  & ! i need a comment here

! empty lines as above are allowed as well
  my_var

Moreover, I guess there is no chance to generalise up-list to something working for fortran. In fact, my semantic-up-context
version can be viewed as an implementation of (up-list -1). It is almost as complex as lexing itself, so I have resolved to
use tags among other things to find the context up one step. Same goes for forward-sexp...


Here are some more of the differences with which I have struggled, am currently struggling with or will need to face one day:

* There is no "return" for function values in Fortran, instead a local variable is used for that. For two variants of function
declarations the local variable has the same name as the function itself -> two tags of the same name, which requires the right
choice depending on the context. (Currently resolved by adding a 'mustbefunction flag to semantic-analyze-find-tag-sequence.)


* Subroutines (= void function) are invoked with a call -> a new derived context is required. Done.


* 'use module_name' (a bit like 'using namespace namespace_name') would require a new context for completion. As far as I can see
completion for C++ offers far more than the meaningful tags.


* Functions and subroutines are not allowed at the beginning of a command. Hopefully just a proper choice of prefixclasses.


* derived types (= struct in C) are declared like

  type(my_type_name) :: my_var

Derived type my_type_name is defined somewhere and a tag ("my_type_name" 'type :type "derivedtype") exists. This looks a bit
like a functionarg context, but I would rather like to generate a new context similar to the subroutine context. This is simple.


* I guess there is no such concept as generic names in C. It looks like

  interface my_subr
    module procedure my_subr_array
    module procedure my_subr_list
    module procedure my_subr_string
  end interface my_fun

The three subroutines my_subr_*** themselves are placed elsewhere.
Now a user can (or even must depending on protection) call the three subroutines by their generic name my_subr.
The choice which subroutine to call is done depending on the type signature. Now completion should take this
into accout and merge the type signatures (including different number of arguments) of the three possible subroutines.
Once some arguments are provided sort out non-fitting type signatures and offer only those still possible. To make matters
worse my_subr interface declarations can be quite scattered and merging is required. This is for another day.


* As mentioned previously, in order to fit the contains part of functions and subroutines into the C tag structure a
"contains" tag of class 'type and :type "contains" is generated, which solved quite a bit of problems. However, this now appears
in the completion list and must be removed somehow. The same holds for modules, represented by type tags of :type "module".
(This problem is partly due to the fact that there is no referencing like my_module::my_fun for a function my_fun contained
within my_module as with namespaces.)

In order to solve this a general tag predicate additionally or in place of prefixclass would be helpful.
Prefixclass implicitely defines such a predicate by

(lambda (tag) (memq (semantic-tag-class tag) prefixclass)).

I am very well aware that some of the not too many uses of prefixclass are like
(memq 'filename (oref context :prefixclass))
and so do not fit the tag-predicate view. But I might have missed something.

For contains/modules the predicate for sorting out those undesired tags would be
(lambda (tag) (let ((type (semantic-tag-type tag))
                 (not (and (string-p type)
                           (or (string= type "module"))
                               (string= type "contains"))))))

The default semantic-analyze-possible-completions routine as well as the one overloaded by clang have some predicates of this kind as well
(filtering out constructors, destructors, operators). I guess I will start experimenting with a new slot :prefixpredicate. However,
I am a bit worried because these concepts (prefixclass, method semantic-analyze-type-constraint and a predicate) somewhat overlap with each other.
Please let me know if you have any thoughts, ideas or suggestions to that.

Thanks for the support
Martin

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