These are chat archives for Fortran-FOSS-Programmers/General-Discussion

16th
Jun 2016
Giacomo Rossi
@giacombum
Jun 16 2016 09:33
Dear all, I've a question regarding deferred procedures and concrete types: in an abstract type I've declared an abstract procedure, that I want to use in two different concrete types. Obviously, in the two concrete types, the procedure does the same thing, but in a different manner (because of the differences between concrete types), so it needs arguments of different type or different rank... How can I overcome this problem?
One (bad) workaround could be to declare the deferred procedure into the abstract type with a lot of optional arguments, but it seems too bad also for me :-)
Stefano Zaghi
@szaghi
Jun 16 2016 09:59
To whom it may concern, the new version of FoBiS v2.0.2 now supports SUBMODULES: also projects that rely on submodules can be automatically built by means of FoBiS, see https://github.com/szaghi/FoBiS. My best regards.
Stefano Zaghi
@szaghi
Jun 16 2016 10:17

@giacombum
To my knowledge ALL deferred TBP must be implemented in a valid concrete extension of an abstract type. So I think you have 2 alternatives:

Optionals abuse

The abstract interface must consider all the optional arguments...

module foo_t
type, abstract :: foo
contains
  procedure(bar_interface), deferred :: bar
end type foo
abstract interface
  subroutine bar_interface(self, arg1, arg2)
  import :: foo
  class(foo), intent(in) :: self
  integer, intent(in), optional :: arg1
  integer, intent(in), optional :: arg2(1:)
  end subroutine bar_interface
end interface
end module foo_t

module foo_concretes
use foo_t
type, extends(foo) :: concrete1
contains
  procedure :: bar => bar_concrete1
end type concrete1 

type, extends(foo) :: concrete2
contains
  procedure :: bar => bar_concrete2
end type concrete2

contains
  subroutine bar_concrete1(self, arg1, arg2)
  class(concrete1), intent(in) :: self
  integer, intent(in), optional :: arg1
  integer, intent(in), optional :: arg2(1:)
  ! use only arg1, arg2 is never used
  end subroutine bar_concrete1

  subroutine bar_concrete2(self, arg1, arg2)
  class(concrete2), intent(in) :: self
  integer, intent(in), optional :: arg1
  integer, intent(in), optional :: arg2(1:)
  ! use only arg2, arg1 is never used
  end subroutine bar_concrete2
end module foo_concretes

In the case the dummy arguments are many this approach is not concise, neither clear.

Avoid the deferred at all

This makes the abstrac less clear, the contract becomes not explicit, but the concretes are not polluted by never-used optionals

module foo_t
type, abstract :: foo
  ! for developers: rember to implement a concrete bar!
end type foo
end module foo_t

module foo_concretes
use foo_t
type, extends(foo) :: concrete1
contains
  procedure :: bar => bar_concrete1
end type concrete1 

type, extends(foo) :: concrete2
contains
  procedure :: bar => bar_concrete2
end type concrete2

contains
  subroutine bar_concrete1(self, arg1, arg2)
  class(concrete1), intent(in) :: self
  integer, intent(in) :: arg1
  ! use only arg1
  end subroutine bar_concrete1

  subroutine bar_concrete2(self, arg2)
  class(concrete2), intent(in) :: self
  integer, intent(in) :: arg2(1:)
  ! use only arg2
  end subroutine bar_concrete2
end module foo_concretes
Giacomo Rossi
@giacombum
Jun 16 2016 10:31
Well, both approaches seems to have pros and cons, and you have highlighted them... is there any other opinion? I prefer the second one: more clean.
Stefano Zaghi
@szaghi
Jun 16 2016 11:44

@/all Dear all, do you have a VIM syntax file for Fortran supporting submodule related syntax?

In particular, let us consider the following snippet:

submodule (foo) bar
contains
  module subroutine foo_bar
  ...
  end subroutine foo_bar
endsubmodule bar

I want:

  • highlight submodule and endsubmodule;
  • enable folding of module subroutine/end subroutine and module function/end function.

Thank you in advance!

P.S. @giacombum I have not a particular preference for your question, it depends on how many arguments are optional.

@tomedunn I see that you have two different Fortran vim syntax. Which is the best among them? The update time is very close...

https://github.com/tomedunn/vim.modfortran => Aug 16, 2015
https://github.com/tomedunn/vim.fortran => Jul 11, 2015

Tom Dunn
@tomedunn
Jun 16 2016 11:58
I think the second one is the one to go with. I can't say I've dealt with them that much since I uploaded them. The first one, vim.modfortran was my attempt to completely redo the Vim Fortran syntax package. But I don't think I ever finished it. The second one looks like what I've been using to modify the existing Vim Fortran syntax package.
Stefano Zaghi
@szaghi
Jun 16 2016 12:02
@tomedunn Just tried both. Effectively the second seems works bettter, i.e. it enables syntax highlight for submodule/endmodule. However, I am not able to correctly fold module subroutine/end subroutine and module function/end function. Is it difficult to improve the folding? Anyhow thank you very much, now your vim.fortran is my preferred Fortran vim syntax :clap:
Tom Dunn
@tomedunn
Jun 16 2016 12:16
@szaghi Glad it helps. Back when I put together the vim.modfortran package I put a good deal of effort into understanding how Vim syntax packages work but I never got very far. Compared to the syntax highlighting package I put together for the Atom text editor writing one for Vim is much more complex.
Stefano Zaghi
@szaghi
Jun 16 2016 12:17
@tomedunn sad to learn this. I like Atom, but I am too much addicted to vim to use anything else...
Tom Dunn
@tomedunn
Jun 16 2016 12:30
@szaghi yeah, I know what you mean. There is a pretty decent mod for Atom that gives basic Vim style keybindings but you still miss out a lot of helpful things. If you want to try to setup code folding for submodules you can find examples in the default Vim Fortran syntax file by searching for region.
Stefano Zaghi
@szaghi
Jun 16 2016 12:32
@tomedunn Thanks a lot, I am not sure if I will find the time, but this information is a great help! :clap:
Stefano Zaghi
@szaghi
Jun 16 2016 16:15
@tomedunn Dear Tom, I have just created a Pull Request for your vim.fortran. I have added the fortranModuleFunction and fortranModuleSubroutine regions for folding these constructs. I was unable to create a region for submodule/end submodule, the regex of vim is not intuitive at all! Indeed, I had few minutes to play with it, but the first saw vim regex really makes me afraid... The two folding regions addes seem to work, but feel free to discard my PR. Thank you again.
Tom Dunn
@tomedunn
Jun 16 2016 18:55
@szaghi I added a region for folding submodules.
Stefano Zaghi
@szaghi
Jun 16 2016 20:21
@tomedunn great! :clap:
Chris MacMackin
@cmacmackin
Jun 16 2016 21:44
@giacombum I'm of the opinion that abstract procedures should only be used when the implementations have the same interface. This requirement is not peculiar to Fortran but is intrinsic to all object-oriented languages. The optional argument choice strikes me as really bad. If you are dealing with a polymorphic variable of this type, then you won't know which argument you should be passing. To be honest, there isn't really any point in having an abstract procedure if it won't have the same interface in all implementations.