You can wrap docopt C++ and use it: https://github.com/docopt Watch their short video (Python) for inspiration. Best cmd line parser ever On Sun, 29 Jul 2018 at 07:26, Gabriel Scherer wrote: > Just in case, Menhir has "demos", small examples of lexer+parser pairs > and an environment setup (example caller code, build script...). The > simplest demo is "calc" > > https://gitlab.inria.fr/fpottier/menhir/tree/master/demos/calc > > a syntax for arithmetic expressions such as "(1 + 3) * 5 + 2". > > It should be fairly easy to get a syntax for set operators by > replacing "*" with "Intersection" and "+" with "Union" in the Lexer, > and integer literals by feature names. > On Sun, Jul 29, 2018 at 2:27 AM Martin DeMello > wrote: > > > > How about "lexing" them into a list of operation tokens, then using the > shunting-yard algorithm to parse them into an expression tree? that would > allow arbitrary recursive expressions and still be relatively > straightforward to process. > > > > martin > > > > On Sat, Jul 28, 2018 at 2:16 PM, Kenneth Adam Miller < > kennethadammiller@gmail.com> wrote: > >> > >> I understand other people have written those things before, and that > it's probably not so challenging to someone else, and I'm not saying I > can't or wouldn't write it, but I'm under deadline pressure, and I think it > would not be looked up on well if I had something with anywhere near so > many features or as much work to deliver since if they even exist. Since I > have to demonstrate this, the first question they are going to ask is "you > spent more than X minutes working on this when you could have been working > on the minimum viable product!! Unhappy!!" So I'm not disregarding the > input I've got, but I think that I can achieve a less robust working > version with the same set of features in a simpler fashion. > >> > >> So, instead I think can get something very near to a full grammar, > while still allowing the fundamental operations I want. Here's what I've > got: > >> > >> > >> type setop = > >> | Intersection > >> | Difference > >> | Union > >> [@@deriving sexp] > >> > >> let list_setops = [ > >> "Intersection", Intersection; > >> "Difference", Difference; > >> "Union", Union; > >> ] > >> let setops_doc = List.(to_string ~f:fst (list_setops)) > >> let setops = > >> let doc = "." in > >> Cmdliner.Arg.( > >> value & opt_all (some (pair ~sep:'=' string & pair (enum > (list_setops)) & pair string string)) [] > >> & info ["setop"] ~docv:setops_doc ~doc > >> ) > >> > >> > >> Instead of having an recursive variant instance in the type setop place > to allow the grammar to be recursive, I will fold over the setops, and add > each one to a map. For example, I might have: > >> > >> --setop Red=Union (Feature1, Feature2) --setop Green=Intersection (Red, > Feature3) > >> > >> So that, as I fold, I will add colors to the feature set. Then, for > whatever nested operations otherwise would have been required, I can just > manually unfold them on the command line. > >> > >> I guess I've solved my problem, but I was hoping to get a recursive > parsing capability on the command line that would have supporting a type > declaration more like the following: > >> > >> type setop = > >> | Result of setop > >> | Intersection of string * string > >> | Difference of string * string > >> | Union of string * string > >> > >> The problem with this is, 1) the constructors are non-uniform so that > there isn't a clean way to specify to the Cmdliner.Arg.value function what > the converter should be 2) The list type of their resulting pairwise > sub-command specifications to the command line (the "enum list_setops" > part) becomes much harder to specify since those also need to be > constructible in the string - type pairs for the list_setops argument to > enum. > >> > >> I suppose my thinking about how to deal with this would be to write a > custom conv to convert the command line input, but to do so it would have > to be recursive, and the Cmdliner.Arg.enum would have to support both > non-uniform constructors and an argument conv to be able to do this > correctly. > >> > >> Does anybody have a better way to capture what I'm looking to do? > >> > >> On Sat, Jul 28, 2018 at 10:54 AM Андрей Бергман wrote: > >>> > >>> Probably a parser combinator with a small language would be a better > tool for that. Parser generators look too heavy, and comman-line parsers > are too light (otherwise they become optparse-applicative, which is too > specific to study it => everyone uses cookbook). > > > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs -- Kind regards, Viet -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs