search

fortran-lang / stdlib

Fortran Standard Library
https://stdlib.fortran-lang.org
MIT License
1.08k stars 166 forks source link

Argument parser for executables #230

Open MuellerSeb opened 4 years ago

MuellerSeb commented 4 years ago

Could this be a place to provide an argument parser in fortran?

Here are two implementations:

milancurcic commented 4 years ago

Yes, I think argument parsing is in scope. See also:

ivan-pi commented 4 years ago

I've found the link for the one from @everythingfunctional:

There has also been a discussion of available modules for option parsing in https://github.com/fortran-lang/fpm/issues/135. Three more libraries I mentioned in that thread are:

I also believe that many of the libraries in the list of popular Fortran projects have their own argument parsers.

Given this much prior art, I think it is a good idea to draw up some kind of comparison table and identify what are the most commonly required features, and what kind of different programming approaches are used in practice.

certik commented 4 years ago

I think we all agree that stdlib should have command line parsing.

One way to get there is to first implement it as a separate library as an fpm package, and get projects use it, and then eventually include into stdlib as we get more real life usage, to ensure the API works.

MuellerSeb commented 4 years ago

AFAICT, https://github.com/urbanjost/M_CLI2 already provides a fpm package.

urbanjost commented 4 years ago

I did not quite get hooked into the process so I do not think that will be pulled in, but yes .. I made a branch that implemented all the command line parsing in the current FPM and all the functionality except the pull/curl request, and tdetermining the compilation order was primitive but I made that private so I could continue experimenting while the more critical TOML interface and gitlib/libcurl/system interfaces seemed to be racing along, and others seemed to be working on the CLI interface. Apparently I did not remove everything I thought I did. So the fpm CLI interface is gone from the M_CLI2 site but if anyone wants me to integrate that into a more recent fpm package let me know.

Sideboard commented 3 years ago

What is the current state on this topic?

urbanjost commented 3 years ago

No active submittal to stdlib I am aware of. There are at least four available as fpm(1) packages. Since what people want is so varied (unix syntax vs. DOS or OpenVMS or new, simple to use versus richly featured) and the attempts at standardizing at least GNU/Unix syntax are at best loosely supported (just use find(1), tar(1) and just about any Unix command to see that is an ongoing process) the hope was there would be a battle royal or a quick development of a new library based on consensus feedback but, scanning for some of the package names I know of on the WWW I do not see any indication that has happened so far.

Are you looking for one to use or looking to submit one? At the bottom of this pageis the beginnings of a list of prior art I started with the intent of moving to the Fortran Wiki (which already has the start of such a list).

What people want depends most on what platform they use the most and whether they are writing one or two large applications or write a lot of small script-like programs.

If you are writing one large application you can invest the time in setting up a complex call; if you write dozens or hundreds of programs you probably do not want to have to look up how to use the routine every time you go to use it.

It seems to me that with no strong movements along this line, and all the issues concerning licensing, features, and such that have made it less than clear what the solution should be, that a new unencumbered library that can parse text files as well as the command line and adheres to the GNU or Sun standards initially, but designed to allow for other syntax such as DOS is do-able and should be added; and a fancier version could still emerge via fpm(1) usage.

I have one that is unfortunately encumbered I would like to make a OS version of that can automatically take the keywords and descriptors and build a screen-mode interface based on the concepts that were used long ago in CDC NOS CCL myself, but that is not anything I plan on doing soon. There were some really nice features in OSes pre-Unix/GNU that got lost. One of them was that the scripting languages had a parser built into them for arguments, and by simply defining their names and descriptions you could call any script in line mode or via an automatically built GUI interface. I created something similiar for F/C/bash and still like it over anything else I have used. Values can also be numeric expressions, which are far easy to enter in screen-panel or X11 mode because the shell is not there trying to expand every special character unless you quote it.

So something like a modernized getopts(3c) (which is what some of the existing art does), that for several reasons should be able to parse a text string as well as command arguments that is under the MIT license is what might make it in at this point, with the expectation something fancier might be added based on popularity. That is the path at least three "recent" languages have taken that are used extensively in CLI environments.

It is amazing how many arguments there can be over what is essentially a common syntax for defining a simple key and value table.

So looking for one to use or want to help write one? If for use, what licensing and syntax are you looking for? I am sure my list is not complete, and it shows at least a dozen to look through; and I put four in fpm(1), and I have versions of two from the list in an fpm(1) format I used for testing fpm(1) I could post in a minute (getopts() and getopts_long() from the list) if the license is liberal (I was hoping the original authors would package them up). If interested in that list, note the list of parsers is way at the bottom in a table format.

Sideboard commented 3 years ago

Motivation: When working on the fpm build --tests feature I had to change the help messages at four(?) different places (in the same file). I thought that an automatic approach like with argparse would have been nice. Now I see that they in fact use M_CLI2 but that apparently needs manually written full text help messages.

It was more difficult that I thought to find information about modules for parsing command line arguments; in part because of search clashes with discussions about compiler options/arguments. And for such an important feature I was surprised that the latest comment here was from September. I would gladly help with this but without consensus that is problematic. We don't want more haystacks, do we? xkcd: Standards

The latest post and the links were quite informative. Thanks a lot!

It is amazing how many arguments there can be […] Beware of your choice of words … :wink:

urbanjost commented 3 years ago

Looking at similar utilities (rust(1), ...) and related utlities (git(1), ...) the full man-page help style fit better with those, and a newly introduced CLI utility benefits from extensive on-hand documentation. Originally, the Fortran man-pages were expected to be incorporated into fpm(1) (they were for a brief moment, and have since been made into an fpm(1) plugin) which were already in that format. The original idea was the pages would be styled to be able to run through something like txt2man(1) to automatically generate HTML and PDF and man-page versions as well. As the documentation has gotten longer it is a little bit of work to edit the code, but it keeps the documentation and the code together, which I generally prefer.

fpm help manual|txt2man |man2html >fpm.html

still actually kicks out a decent document; albeit it needs a little tweeking: fpm.html.pdf

And of course that could be actual roff man-pages, LaTeX, and so on. In my own little world I write text as a $BLOCK using the parent of the prep(1) preprocessor and it gets converted into a man-page, HTML, gets spell-checked and either left out, turned into ford(1)/doxygen(1) comments or CHARACTER variables for use in help or an actual subroutine (for use with the "kracken" parsers) in the resulting .f90 files. I have been doing something similar for so long I am totally biased but the concepts if not the implementation (my own build system suffers from a lot of "if it is not broken, don't fix it", and is showing it's age) ar that is more mathematically developed as well) I get REALLY frustrated at how it can take hours to write and document something I could do in a few minutes "in the system". I think it will look totally different, but fpm(1) is going a long way towards creating a friendlier build system for Fortran. It is hard for some people to picture apparently, but in a little proprietary corner of the world it is easier to make a quick utility with Fortran than with Matlab/Python/Bash so I know there is a lot of potential in what is coming out in the OS world now. I REALLY miss full-featured graphics and regular expressions in Fortran in the real world though.

So we should at least have argument parsing (but it took thirty years to get date and time standardized in Fortran so I am used to being patient -- things are changing rapidly now). If you install plugins like fpm-search and fpm-man and then see how the help style is homogeneous I think you might find the approach isn't without it's benefits.