On Fri, 1 Jun 2012, Blaise Bourdin wrote: > > On Jun 1, 2012, at 2:23 PM, Jed Brown wrote: > > > On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <bourdin at lsu.edu> wrote: > > Apologies, will do next time. That would also have helped me realize that I > > had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am > > attaching the patch I was planing on submitting. > > > > Out of curiosity, what is the rationale for not wanting an explicit > > interface? As far as I understand, the fortran standard mandates an > > explicit interface in this situation (array of strings). I would understand > > in the situation of pure f77 compatibility for instance, but we threw this > > away with the iso_c_binding module anyway... > > > > Fortran modules are horribly nonportable from a build system perspective > > since every compiler manages them differently. > > I agree. Some compilers even change the flag names from one release to the > next. > > > > Having the interfaces requires those extra interface files in the includes > > that we already hate so much, and we can't protect the headers (to make > > including the right ones simple like in C) because you have to include them > > for every subroutine. > > Not really. You don't need to include the modules in each subroutine or > function if they are included (used) in the Program or Module in which the > function is defined > > > > > I think it would be better [1] for the "modern" Fortran users for PETSc to > > do everything with modules, using explicit interfaces for all functions, > > and datatypes for PETSc objects. > > Apart for [1], I fully agree. I actually think that there should only be two > way to use fortran: the old f77 way without any type checking, interface, and > where all petscobjects are integer, or the right way which you described. > > > > Unfortunately, that forces people to spell out things like type(Mat) [2] > > and XGetContext() either requires an explicit interface written by the user > > [3] or use of the ISO C bindings in the interface [4]. > Not really. As long as your context is not too large (so that allocating a > copy and copying the data won't kill you), you can always write a generic > interface for XGetContext that returns an array of your favorite data type, > then use transfer. And when your context is large, you should pass by address > anyway). Conceptually, it is not really different from casting into a *void. > McCormick has a nice writeup on this > http://www.macresearch.org/advanced_fortran_90_callbacks_with_the_transfer_function > > How does using iso_c_binding helps with a fortran library called from > fortran? > > > I can think of no explanation for this absurdity other than that the > > Fortran language standards committee is the most successful global trolling > > agency in modern history [5]. > > > > > Perhaps introducing f2003 in petsc was a bad idea, considering the large > > variety of compilers you need to support. If you feel that it introduces > > more issues than solving problems, feel free to strip the PetscOptionsEnum > > and PetscBagRegisterEnum bindings. They could easily be packaged separately > > for the few people who will ever need them. > > > > [1] Better, but it would be best for them to stop using Fortran. > Why not. But what is the alternative knowing that I am not willing to give up > array sections, operator overloading and vector operations? Are you going to > suggest that I switch to C++? > > > [2] No #includes means no macros [6] and no equivalent of typedef. > The only macro I would miss are CHKERRQ and SETERRQ. I would actually make an > exception for these two. For numerical and string types, the fortran way of > doing typedef is kind. > > > > [3] Disaster because (a) it is maintained by the user with no way to check > > that it is correct and (b) the user may need multiple incompatible > > definitions in the same project. > > [4] Indeed, the best way to write a Fortran library called from Fortran is > > to use the ISO C bindings. > > [5] The people who dream up ways to link MKL and the Portland Group deserve > > honorable mention. > > [6] Type macros are terrible anyway because of the aforementioned punchcard > > nostalgia leading to different projects adopting different line/format > > styles and compilers having no portable way to select. > I don't know of any compiler which does not default to free form for > .f90/.F90 files, do you? Free format has been around for over 20 years. That > some people insist on coding on 72 cols (or is it 78?) in the days of large > screens is beyond me indeed. > > So I guess that you guys don't want an explicit interface for > PetscBagRegisterEnum, right? I'll fix the harmless bugs in the current > binding, then. >
Hm - we do have explicit interfaces - for ex: VecGetArrayF90() does not work without it.. Satish > Blaise > >
