Finish the initial argument class

[Bijaelo]

This issue is a simple checklist to keep track of the progress of the "argument" class.

The first version is going to be a "rough" but "complete" sketch that can handle the standard input types, in a similar but not identical manner to the python argparse module.

For this the argument needs to

• Accept cmdline flags (at least 1 and 2, but possibly more)
• Be knowing of their own name
• Have knowledge of how to be restrictive to a certain range of argument count (narg)
• Be able to handle how to be a required argument, and its interaction onto narg
• Be able to be a flag, and have methods for handling being the best flag that it can be
• Be able to carry a default value, and know how this should be handled (specifically its interaction with required and narg)
• Should have knowledge of different possible actions and their effect on other parameters (such as store_const, append_const, store and so forth)
• Note that with R's data structures some changes makes sense here
• Be able to handle const values (with specific actions)
• Be able to restrict itself to only a set of choices
• It should be able to contain a parser.func (an R function) which can be used to parse the arguments
• It should obviously be able to parse its own arguments, eg. have knowledge of how to call parser.func and this
• later on we'll look at handling help messages, meta variables, etc. But for this I think I'll split the class into different children (the plan has not been sketched yet).
• again later I should implement some standard methods for "integer", "double" and "string" (the latter returns "as is") to avoid the repeated call to the R api (as much as possible).
• Shortly after implementation is done it should be able to handle a call to R's as function, and be able to test if a string is a valid function. The method should be
  1. Test if parser_func is a function, if so use it
  2. Test if parser_func is a string, if not throw error
  3. Test that parser_func string is within builtin methods (once implemented) if so, use it
  4. Test that parser_func string is an actual function using get_function (using Rf_findFun from R.h, see Rcpp::Function)
  5. If everything else fails create a call to the R function as, using the S4 method for coerce.

This should ensure somewhat optimal speeds.

The argument should not necessarily need to know whether it is a "positional" argument, as this is handled by the parser itself. Help message formatting, meta data and so on should come in once everything else is setup, classes are split into sub methods and so on.

Note that the argument of argparse type is redefined as parser.func (or parser_func in Cpp), as this is a more apt naming for the input.

[Bijaelo]

It should also be possible to specify whether parse.func is vectorized or not, and whether the function needs input as a list, vector or individual arguments. All of this should only affect argument::getUnparsedArgs, and should be the default return type for this function.

[Bijaelo]

spent a few day grumbling to myself about some problems with vectorization and const. I believe I've tackled this problem the wrong way and went into a trap of thinking as a python programmer, while developing an R package. Basically having the possibility of action = "append_const" leaves a problem in vectorization. The value of const should likely not be parsed by the function, so it has to be added in after evaluation, meaning the position has to be memorized and the result reordered after evaluation in order to insert the value (in case the order of arguments to commandline matters, which it may). This looses some of the "nice" features of R, for a feature that is unlikely to be very useful. This got me further down the constellation and started wondering, well if we want to utilize vectorization, how should we handle multiple arguments? Is -f A B C equivalent to -f A -f B -f C? And how should narg be handled if -f A B C translated to f(c(A, B, C)) and -f A -f B -f C translated into c(f(A), f(B), f(C))?.

Well realizing that I am definitely over complicating this predicament I've decided upon my own solution.

Through parse.fun.opt I'll allow specification of how to handle multiple arguments, whether they should be vectorize-all (default), vectorize-each, vectorize-none, translating into

1. -f A B C = -f A B -f C = f(c(A, B, C)) for vectorize-all
2. -f A B C = f(c(A, B, C)) != -f A B -f C = list(f(c(A, B)), f(c(C)) for vectorize-each
3. -f A B C = -f A B -f C = list(f(A), f(B), f(C)) for vectorize-none

basically this would allow a more complex evaluation scheme with position memory. narg would have to be handled specifically for each case. v-all would count the number of vector components the same for v-none, while v-each would have to count how many times -f is supplied.

Now append_const has a clear definition for vectorize-each and vectorize-none, as I'll only have to memorize the position and add them to the outcome list.

For optimization it'll make a lot of sense, to create a class and use traits to handle these cases, or in another way ensure that we only have to evaluate this once. Rcpp does this when growing lists and pairlists to check for names here with the traits defined here. Using a similar approach to handle this drastically improve readability. In general I believe I'll be moving more and more towards an Rcpp style of coding, as this project develops. A reference for traits and implementing is here.

[ ] Define new action set, based in this implementation (as "append" and "concat" are now handled by a combination of narg and parse.func.opt[["vectorize"]]), and make a plan for their implementation.
[ ] Consider a more readable evaluation plan using traits. For example it would be more readable to have argument::parseArgs(::traits::types::flag) for parsing arguments for flags and argument::parseArgs(::traits::types::const_append) for action = "const_append". I could even define argument::parseArgs(vector<string>&) and let this be the main method for calling cmd_do_docall (in the future this will instead be a call to an overloaded definition of Rcpp's Function).
[ ] Consider alternatives

Maybe it is a better idea to make a seperate class for flags and other types of arguments. With seperate handling. I have toyed with that idea as well.

[Bijaelo]

Update on my the packages current status.

The package as is will undergo some reworks. As stated in my prior message, going down the path to a straight-up argparse clone is ripe with problems. First of all, with R's data structures and implementation the type argument makes very little sense in an R setting, unless we want to restrict drastically restrict the types of input that we may use, either restricting function input to string or to have a naming convention that does not make rational sense, as we would be using function such as as.numeric for type argument. Instead the function for parsing will be parser_func.
Next, R is heavily reliant on vectorization for performance. Calling functions such as as.numeric on each input will be drastically slower than calling it on the full vector. Python does not rely on vectorization to the same degree, if at all in base python. This gives rise to the question how input should be passed to our parser function. Should it be individual components, (x[1], x[2] etc.) or should all arguments be passed simultaneously?
This question goes on to how multi-input arguments should be handled. If arguments are passed always simultaneously we just create one long vector. But should -f a b be handled differently than -f a -f b? Both could be handled in the same manner, or the latter could be handled as 2 calls to our parser function, or alternatively it could be handled as parser_func(a, b) while the first could be handled as parser_func(c(a, b)). All of these seem valid, and in my opinion should be plausible with a sensible default choice.

Originally this was all contained in the argument class, and this quickly caused the project to become difficult to extend and highly unreadable. As such I the next step of the process is to branch of the current version 0.0.0 and split the current implementation into multiple sub-classes, that each can be individually extended. The new implementation should have a parser_func class to hold and handle calling of the parser function with inputs (but not contain inputs or results themselves), a printer class to handle help messages, a argument_handler class for digesting arguments from the commandline, a narg class to ensure the number of arguments are handled correctly and possible a few other classes as we go along.

I'll be creating a flowchart for the package's current version and adding this to the repositories new branch once it is finished. Just a rough sketch.