Should nlopt-wrap be renamed to nlopt-f?

[ivan-pi]

Pros:

• makes the Fortran language recognizable (hopefully)
• helps distinguish project from R nloptwrap
• helps promote convention of -f for Fortran projects (i.e. ˙toml-f`)

Cons:

• hides the fact that C code is being wrapped
• search engines could mistake this for nlopt.f file generated by the original NLopt repo or point to the original NLopt Fortran reference (https://nlopt.readthedocs.io/en/latest/NLopt_Fortran_Reference/)

[awvwgk]

Difficult I considered nlopt-interface since it mainly provides interface modules, but once I started writing the class to hide the actual C-interfaces it seemed more than just an interface library but an actual Fortran wrapper.

A couple of projects carry the fortran suffix (json-fortran or datetime-fortran) / prefix (fortran-csv-module or fortran-curl), naming the project nlopt-fortran or fortran-nlopt sounds reasonable. Continuing the toml-f series with a nlopt-f has the certainly the advantage of being briefer than using the full language name.

[awvwgk]

For toml-f I'm usually calling the project TOML Fortran when not talking about the identifier used in the build system. Similarly, I would consider this project as NLopt Fortran bindings in its full name which shortens to nlopt-f as practical identifier. Sounds reasonable?

[ivan-pi]

Sounds good to me. I'm considering renaming the interface to METIS I maintain too.

[certik]

This is a common problem. See the discussion at symengine/symengine.f90#7. I would recommend nlopt.f. This is consistent with other such efforts. Julia uses the .jl extension, and Python wrappers often use .py.

[awvwgk]

I don't think it is that clear, especially for Python a common strategy is to create py<name> packages, or have projects with a python prefix or suffix. I haven't seen any .py so far yet except for symengine.py so far. In contrast the Julia community has established a clear guideline to have all projects end with .jl.

For Fortran we currently see two dominant approaches, one is adding fortran as prefix or suffix, the other is including f in the name (fson, fmetis, toml-f, ...). For bindings in particular we could want make the original project recognizable, therefore this approach is very suitable. For regular projects it feels a bit redundant. I haven't much projects beside symengine to actually use a suffix of the .f90 kind so far. For all the drawbacks we introduce by using a dot in a package name I'm not convinced that this is a useful convention.

[certik]

The reason is that there are not many modern Fortran wrappers to other libraries. That is about to change. So establishing clear conventions is crucial.

So far you decided on -f. I have not seen any other language using that. That was were I was coming from. The .f convention at least has support in other languages.

What drawbacks has having .f in the name? I can't see any.

The general logic is as follows:

• For Fortran package written in Fortran, we do not need to append anything (although the Julia convention is not bad either to always append)
• For wrappers into Fortran, it is usually necessary to append (or prepend) something, to distinguish the name of the repository from the original package (typically in C or C++).

[aslozada]

Some formats (styles) for Fortran wrappers names:
fortran-<>
Fortran<>
fort<>
<>FOR<>
f<>-wrapper
<>-fortran
<>tran
f<>

see http://fortranwiki.org

[certik]

@aslozada thanks! Considering all these, I think I prefer <>-f or <>.f.

[awvwgk]

There are two things here to consider, first the repository name and the package name. I usually try to match them because it is more intuitive. Adding .f as extension would only be a change in the repository name not the package name, for the following reasons:

• the dot is a special character in TOML, it would always require escaping when depending on a project including a .f in the project name
• fpm disallows (current head) dots in the project name (requires discussion upstream whether we want to change this)
• using a package name with .f regardless would produce unintuitive names for the automatic execuables, like a something.f executable, or a libsomething.f.so.0 shared library, this breaks with existing conventions on Unix

For those reasons, I would only consider using a .f extension for the repository name, but not for the package name. There is one important argument for not using nlopt.f in this context, which is that the name nlopt is already taken by the upstream project wrapped here.

[certik]

Take symengine.f as an example. In fpm (once it works with fpm), you would depend on just symengine, not symengine.f. That fixes I believe all the issues your brought up.

Now take nlopt.f. Why cannot you simply depend on nlopt in fpm?

[awvwgk]

Now take nlopt.f. Why cannot you simply depend on nlopt in fpm?

I don't think it is that simple, since this project is not nlopt, the name is already taken by stevengj/nlopt, the project wrapped here.

If I'm using nlopt as name for this project, the created libraries libnlopt.a or libnlopt.so will be misleading, also I can't see how I can depend in a sane way from the Fortran libnlopt.* on the actual libnlopt.*, especially in case of dynamical linking. Finally, I can't install my project in the same prefix as an existing nlopt installation, which has practical consequences when packaging.

[certik]

This is a bit of a unique case that there are two competing Fortran wrappers, so a different solution might be chosen.

I was having in mind the general case of being part of the upstream project, or the only wrappers "in town".

[awvwgk]

Closing this in favor of the general discussion at https://fortran-lang.discourse.group/t/1701.