Re: [CEDET-devel] semantic-analyze-current-context for fortran functions and subroutine

[Martin S. <Mar...@gm...>]

Hi Eric,

 >> 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
>
> That doesn't look too bad.  MATLAB code has similar problems, and I
> wrote a simple routine that just does a quick check for ... (the
> continuation sequence) and then can skip over all intervening blank and
> comments.  Though I don't have this type of semantic support, the same
> type of fcn could be used to skip intervening non-code.  We'll just need
> to call out to a routine for skipping such text.
Fortran continuation lines are even a bit easier. I have two regular 
expression workhorses for that, f90-rx-ws-or-contline and 
f90-rx-ws-or-contline-opt, one requires at least one whitespace 
character possibly mixed with a continuation line, the other also 
matches the empty string or continuation lines without whitespaces. 
Whenever a typical regular expression in lexing or ctxt routines require 
a whitespace charater, I plug in those constants and off it goes. But 
together with the fact that forward-sexp and the like does not work 
properly for fortran, it seems that I really need to overload the ctxt 
functions (as they mostly work, I will do that later on).
BTW: Looking at the ctxt functions I actually came across a bug in 
semantic-ctxt-current-argument-default, which simply counts argument 
separation characters (i.e. ","), without taking parenthesis into 
account. For myfun3(fun_for_arg1(i,j), arg2 ...) the context analysis at 
arg2 thinks it is already at arg3...

> One is that when it comes to parsing tags, or interpreting code, I let
> the compile figure out what is "correct", and end up with a very
> permissive code that will try to provide a tag set or completion
> suggestion.  This is for a few reasons.
>
> First, most people try to write correct code, and don't want me
> providing bad suggestions.  Second, I'm kind of lazy.  Third, the parser
> or completion engine sometimes is missing some data, so I'll just try
> for whatever I can figure out to work around the issue.
I am not sure what you mean by that with respect to the outlined fortran 
specific contexts.

> My second thought is around supplying new context types.  If something
> makes sense, we should consider supporting it in the core.
To try it out I have added new context classes for
*  call my_sub
*  type(my_derivedtype
*  use my_mod
and it works fine. Having an OOP like framework (I rather like to 
compare it with haskell typeclasses) seems to call for just such 
language specific extensions without the need to put it into the core.
In order to make it work I have overloaded 
semantic-analyze-current-context by refactoring the default routine. I 
think I might have a first version of the f90 parser ready in a couple 
of days, then you can judge whether, what and how parts of the code can 
be put back into the core.

(From what I see C/C++ completion can be improved with having more 
specific context classes as well. For exmaple completion for 'using 
namespace xxx' does not complete context dependent at xxx. But I do not 
know whether there is any demand for such improvements.)

> I would think a predicate of things to remove from a completion list
> would be fine.
>
> The different filters you listed do seem to overlap, but come from
> different places.  The prefixclass is basically from
> `semantic-ctxt-current-class-list' is based on where you are.  For
> example, what you complete is different if you are in a fcn body, or in
> declaration space.
>
> The typeconstraint is if the value is being assigned somewhere.
>
> Your predicate is much like the constructor/operator case.  Those types
> are just not relevant and should be skipped.  Thus, I think refactoring
> to make that behavior accessible to fortran modification makes sense.
After playing around a bit I have ended up with a pretty short 
semantic-analyze-possible-completions function which mainly consists of 
piping together a number of tag filters. Now plugging in a general 
purpose filter function (for contains/module tags) becomes really easy. 
The next step would be to make this filter sequence language 
customisable and my f90-overloaded semantic-analyze-possible-completions 
might be a possible draft for a refactored core function. Anyway, the 
overloading mechanism is nice to try these things out without touching 
the core.

Martin