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

On 02/11/2015 05:19 PM, Martin Stein wrote:
> 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...

Oy, thanks for that.


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

That was a long winded way to say that false positives (allowing a bad 
syntax in Semantic APIs) is generally not a problem.

  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.

Great!  That was indeed the intent for making making these functions 
overloadable.  Hopefully your experience will make it easy for us to 
review and refactor the core allowing the fortran extensions to be simpler.

Eric

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