CLI argparsing DSL

[refaktor]

From the Lobste.rs thread:

So regarding argparsing: It's a spectrum and everything has tradeoffs, additionally it's a matter of taste. Take python for example. You can construct quite complex parsers, but it's verbose. Still way better than what you need to do in bash. On the other end of the spectrum, we have something like Raku, which does everything for you automagically, but robs you of certain freedoms, it also doesn't really follow the default unix-conventions, if I recall correctly, I'm not sure though. I think ideal would be some sort of DSL that allows for absolute minimal syntax for the common cases, and still allows you to expand for more complex examples. E.g.: to just have boolean flags, argument flags, i.e. flags with additional value, and positional arguments you should have to write nearly nothing. To have modes (cargo build, cargo run), you should not need much more. To restrict the valid values, to add help-strings or to have flags with multiple arguments, you could then use more elaborate syntax.

https://lobste.rs/s/vw12iy/when_if_is_just_function#c_eyoih5

[refaktor]

Idea is moving towards using the validation dialect patterns and customize them to argument specifics. Because validation in a way should also support many of the patterns that CLI argparsing could use and argparsing is at the end still a input validation problem.

Just thinking outloud, any feedback is very much appreciated as I haven't thought about this that much so far and maybe I'm overlooking specific cases.

Moving Parts

• executable - example: git add --dry-run file.txt
• commands - example: git add --dry-run file.txt
• flags - example: git add --dry-run file.txt
• arguments - example: git add --dry-run file.txt

Variations

format:

• flags: short and long version - example: -v / --verbose
• arguments: quoted or unquoted - example: echo hello / echo "hello"

one:

• executable can have 0-N arguments
• executable can have 1 (command)
• executable can have 0-N (flag)s

each

• (command) can have 0-N arguments
• (command) can have 0-N (flag)s

each

• (flag) can have 0-N arguments

let me know if I am missing something.

[KnorrFG]

Hey, let me add to this:

1. I also find the following scenario important: I might have multiple modes (e.g. git commit, git push), but a flag that is shared between all of them, e.g -p in git. There should be a way to specify arguments that are mode independent (i.e. flags that can be used with every mode, and are typically passed before the mode name), without having to define them for each mode.

Additionally, here's a list of interesting References:

• Rust's clap crate
• Python's argparse
• Python's click
• Rakus automatic generation

Clap and argparse are both somewhat verbose. Both of them support every feature one could wish for, and return a data structure representing the parsed arguments. Click and Raku derive the argument parsing from function signatures. Click has the downside that it needs quite a bit of boilerplate to add additional information and Raku simply doesn't offer that option. In principle, I like Click's approach best, and the boilerplate could be reduced quite a bit by a nice DSL.

[refaktor]

Yes, that would be the option "executable can have 0-N (flag)s" ... all options should be possible at the same time :P ...

I will go over the links you posted. Thank you!

[refaktor]

Just update, I'm experimenting about this. Currently, I am working of this case, maybe it's not all encompassing:

• I have executable "exec"
• it has optional flag -x that has an optional integer argument, default is 2
• "exec" must receive one of two commands cm1 and cm2
• cm1 has two optional flags,
  • one -a has no arguments
  • another -b takes two positional decimal numbers
• cm2
  • takes one or two positional arguments (strings, second should be email)
  • and optional flag -c that requires one argument integer

I will later also think how we can specify interdependencies, do we want to have optional argument with no default, but that program later mush handle, since Rye has no passable nulls/voids/etc ... interaction between something like "some" "any" and optional / required ...

This is just first pass idea:

rye .Argparse {
	'x 'exec "flag x help" optional {
		:val optional 2 integer
	}
	some {
		<cm1> "cm1 help" {
			'a 'add "add help" optional true boolean
			'b "b help" optional {
				:val1 required decimal
				:val2 required decimal
			}
		}
		<cm2> {
			'c optional 0 and integer   ; should we conflate flag and flag + one argument case?
			:val1 required
			:val2 required email
		}
	}
}

[KnorrFG]

Hey, I'm happy to see you working on this. I like it, I only got to say: to have a simple boolean flag, I find optional true boolean quite verbose, although I understand that this may be the consequence of the relation to the validation dialect, and I can also accept it. But maybe a type could be derived from a default value?

Looking at this also makes me wonder how it would be combined with the rest of the rest of the script, could you extend it with some code that uses this parser defintion? Also I'm wondering about how positional arguments would look.

I normally wouldn't comment that much on an example like this. I don't want to be annoying, but I also don't want to be dismissive, given that all of this is coming from my lobste.rs comment. If you feel like I give too much feedback, please just tell me.

[refaktor]

Hey, I'm happy to see you working on this. I like it, I only got to say: to have a simple boolean flag, I find optional true boolean quite verbose, although I understand that this may be the consequence of the relation to the validation dialect, and I can also accept it. But maybe a type could be derived from a default value?

haven't thought of it, so interesting thought. Hmm ...

otherwise to me, consistency trumps compactness, but consistent rules can also be made more compact

You are not commenting too much, or too little ... your views have been valuable, especially because I also want to have this solved, but I haven't been thinking about it much so I'm sort of leaning on your feedback for info and motivation to do it now. Thanks.

[refaktor]

I've added new value type flagword to Rye (parser and runtime). It should be usefull for this DSL. It's available in new release v.0.0.88

more about it:
https://www.reddit.com/r/ryelang/comments/1opusig/new_dsl_for_working_with_external_processes_cmd_sh/

I hope to get started with this DSL this week.

[refaktor]

I made some progress on this ... it might now include all it could at the end but I want to make some steps to get to something useful we can then use and evolve. I will have it on github, and demo on reddit this week I hope.