[racket] raco command naming convention

I think `raco mcfly' with subcommands works better. I'd also advocate
short names --- `update' instead of `update-dev-links', say.

Note that `raco' automatically accepts unambiguous abbreviations, so
that `raco dec' works for `raco decompile'. I'm not sure how well that
will work in the long run, but for now, I use shorthands like `raco
dec' and `raco dist' a lot. I can similarly imagine abbreviating `raco
mcf up'.

It's true that a `raco' convention of short names in nested namespaces
is different than the Racket convention of long names in a flat
namespace, but I think that's because a command line is different from
programming in Racket (but it's also good to provide a Racket interface
to a tool, of course).

At Sat, 24 Dec 2011 19:54:46 -0500, Neil Van Dyke wrote:
> Regarding adding "raco" commands, any opinions on whether long command 
> names are appropriate?
> 
> For example, assuming that I have a package, called McFly, that defines 
> a few "raco" commands, which of the following is preferred?
> 
> 1. raco update-mcfly-dev-links
> 
> 2. raco mcfly update-dev-links
> 
> That is, should the McFly package add multiple "raco" commands with long 
> names, or should it add a single "raco" command with multiple subcommands?
> 
> An advantage of adding "raco" commands with long names is that they show 
> up in "raco help".  Secondarily, "raco help" output could be used to 
> complete "raco" command names, although this alone wouldn't give it 
> enough information to complete arguments after the command name.
> 
> Another advantage of the long names is that it's a single namespace, is 
> that, if multiple packages are adding operations, the user only has to 
> remember a sensible name for the operation, not which package/command 
> unver which each operation is effectively categorized.  (Analogous to 
> how we generally use variable names in Racket.)
> 
> A disadvantage of the long names is that they push the formatting of 
> "raco help" output wider.