What's left to do

[moodymudskipper]

• [x] check that back and forth conversions work from tags, tag_adverbs, and external adverbs, see if error message can be helpful
• [x] better doc
• [x] forbid ... arg in tags explicitly
• [x] copy some unit tests from tags package, so tests don't have to be run on both all the time
• [x] explain what's a function operator/adverb in the doc
• [x] handle argument conflict (define what should happen, and what to do for it to happen)
• [x] should we allow lazy arguments in tags ? They're not necessary this far and if we keep it this way new formals are usable directly in the tag definition instead of using eval.parent(ARGS[["arg"]]). If we don't allow them now and decide to allow them later it will be a breaking change.
• [x] should we find a way to use CALL() instead of CALL in tag definitions so we don't waste ressources precomputing stuff that won't be used ? They could have one argument eval that would trigger evaluation in the parent if relevant, so CALL(eval = FALSE) would be the same as current CALL and CALL() would be the same as current eval.parent(CALL), and ARGS(eval = FALSE) would be the same as current ARGS while ARGS() would be the same as current somewhat awkward lapply(ARGS, eval.parent, 2). Not sure if these functions could live in the package namespace though, they might have to be defined in the enclosing environment (and will sometimes have to refer to their calling environment). If they're not defined in the namespace maybe we should add them with appropriate errors, so we can also have dedicated help files. This of course breaks all current tag definitions in tags.

Artem's comments :

• [x] Include a link to https://github.com/moodymudskipper/tags in its first mention: "See also the package tags which includes many tags defined with the help of this package."
• [x] Consider including an example in “Formalism” section to use during definitions. For example, you can take the example in the first sentence of “Syntax” section some_tag(tag_arg)(fun)(fun_arg), and refer to individual elements as you define input function, manufactured function, etc.
• [x] Typo: “Thes ecome directly from the package tags.”

We decide not to support ... argument in tags, this could lead to complex "dot collision" with the dots of the input function, in practice this can be dealt with by providing a list argument which can be a call to list, list2, exps, vars etc...

[moodymudskipper]

The new system with CALL() etc has been implemented and is cleaner, now :

• [x] all tags need to be translated with new syntax
• [x] exported functions CALL() etc should be created and trigger error, linking to help
• [x] help regarding the pattern helpers should be moved to ?CALL
• [x] readme should be edited

[moodymudskipper]

done!