<div class="gmail_quote">On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <span dir="ltr"><<a href="mailto:bourdin@lsu.edu" target="_blank">bourdin@lsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":3da">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.<br>
<br>
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...<br>
</div></blockquote><div><br></div><div>Fortran modules are horribly nonportable from a build system perspective since every compiler manages them differently. 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.</div>
<div><br></div><div>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. 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].</div>
<div><br></div><div>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].</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":3da">
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.</div>
</blockquote></div><br><div>[1] Better, but it would be best for them to stop using Fortran.</div><div>[2] No #includes means no macros [6] and no equivalent of typedef.</div><div>[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.</div>
<div>[4] Indeed, the best way to write a Fortran library called from Fortran is to use the ISO C bindings.</div><div>[5] The people who dream up ways to link MKL and the Portland Group deserve honorable mention.</div><div>
[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.</div><div><br></div>