[Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

I have been trying to hack on command-line.parser to add the ability to
call it with commands. I am too far out of my depth in both
understanding how to debug the situation, but also it’s difficult to
work with since all of the vocabs are used for the listener already it
seems?

Ideally the API goal would be like OCaml’s Cmdliner Cmd
<https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html>
which is for CLIs that aren’t prompt-based, command-driven such as with
Git, Pijul, & so on. Currently there is no ordering of arguments as you
are either an option or positional, but command styles have recursive
units that can nest other options / commands which could have their own
help texts — where once a cmd type is found on in the set of commands
from the argument sequence, the rest of the arg sequence should run
(parse-arguments) on a new options for the command.

Some tools like Git & Pijul can dispatch out from a primary program to
subprograms based on the name, but if start times are slow or executable
sizes are big, this isn’t as preferred by users, which is probably the
case for Factor — especially if using the interpreter as factor -run=foo
bar baz --qux "quux" (would this then call factor -run=foo.bar baz --qux
"quux" which then calls factor -run=foo.bar.baz --qux "quux"?).

What I intially tried was using -- to get the rest of the arguments, but
aesthetically this isn’t ideal, but more importantly you would lose the
ability to get help text for the subcommands. --help currently can
*only* show the top-level help & it can’t be surpressed while all much
of the API is hidden behind <PRIVATE> to try to assemble the pieces
yourself. -- could also be assed to a prompt-based setup as input, like
fdisk.

Is this a feature request, a call for help? I’m not entirely sure… 😅
but it does seem the like a missing feature that could be tackled for
UX as prompt-style CLIs have gone out of fashion & folks — my Fish
session included — want shell completions without wrangling the state of
a prompt (I have failed to set up a disk with fdisk on more than one
occassion).

… Or should I just be doing my own argument parsing & avoid
command-line.parser (recently moved from /extra to /basis) if it can’t
fit my needs?

---

I had written a single test as a goal:

CONSTANT: COMMANDS H{
   { "add" H{
      T{ option
         { name "a" }
         { #args 1 }
         { type integer }
      }
   } }
   { "subtract" H{
      T{ option
         { name "s" }
         { #args 1 }
         { type integer }
      }
   } }
}

{
    {
        H{ { "cmd" { "add" H{ { "a" 1 } } } } }
        H{ { "cmd" { "subtract" H{ { "s" 1 } } } }
    }
} [
    {
        T{ option { name "cmd" } { cmd COMMANDS } }
    } {
        { "add" "1" }
        { "subtract" "2" }
    } [ (parse-options) ] with map
] unit-test

As well the type I would assume…

TUPLE: option name type help variable cmd default convert
    validate const required? meta #args ;

TUPLE: command name help options ;

But got stuck trying to figure out where / how get this in
parse-arguments.