On Feb 15, Philippe Meunier wrote: > Matthew Flatt wrote: > > * Some of us have discussed collapsing `setup-plt', `mzc', `planet', > > `plt-help' and (in case I've overlooked any) other miscellaneous > > programming tools into a single `rico' executable. > > I see that as mixing apples and oranges. Then there's a strong risk > of it ending up like cvs, where I could never remember which > '-something' options I could use or not use in combination with > which 'update', 'log', etc. sub-command, and where the same obscure > '-something' option had a different meaning depending on which > 'update', 'log', etc. sub-command I was in the middle of using (or > was it that the same option had a different meaning depending on > whether it appeared before the sub-command name or after? I can't > remember now, nor do I want to...)
That points at some strong reasons in *favor* such a central executable. First, note that there is already a mess: `setup-plt -h' has a huge number of options and some very different uses, `mzc -h' is ... insane, and there are bits of functionality that are unclear whether they're in one or the other (is it obvious that `mzc' creates .plt files? could you answer Robby's quick question?). It also doesn't help that sometimes there's "setup-plt" and sometimes "Setup PLT", and that `planet' already does its own subcommands (which makes sense to avoid an mzc-like mess). Second, there shouldn't be any confusion: `rico -h' would describe its own options and perhaps the list of available subcommands (or maybe `rico -l' would do the latter), whereas `rico subcmd -h' would return the help specific to that subcommand. The problem with cvs (and with svn) is that there are some options that all commands receive and they can be specified either as an argument to the main executable or the subcommand -- for example, `svn log -r 123' and `svn -r 123 log' are equivalent. It seems to me that this is easy to deal with by choosing the second one: specify the globally accepted flags first, and that propagates to the subcommands via the usual channels (eg, parameters). To make things more concrete -- there is a problem with some flags now that should be accessible for different launchers but are not: `-X', `-S' and `-A' are such examples. (And yes, the similarity to parameters and/or environment variables is obvious.) Things can get problematic when there are a few subcommands that want to share the same kinds of flags -- for example the `++ccf' flag to mzc applies to two "subcommands", and the `--verbose' flag to setup-plt. These are two good cases to consider: in the first case, it makes sense to have both `rico compile' and `rico link' abstract over their shared flags somehow so the same flag is used in both. In the `--verbose' case, that's something very generic that can apply to any tool -- and in cases of flags like that it's probably better to come up with a central functionality that does what verbosity needs to do instead of some central code for the flag -- in this case the logging facility fits right in, so having `rico' consume `-W' and `-L' will cover it as long as subcommands use logging for their output. > Robby Findler wrote: > >FWIW, part of this is motivated from the fact that we're coming > >from a situation where the dev tools are spread out among a bunch > >of executables and you'd never really guess where some of the > >functionality is (quick: where is zo-file decompilation?). > > But it's only going to move the problem by one word to the right by > adding the word 'rico' in front (quick: which combination of rico > sub-command and option does zo-file decompilation?) Different answer than Robby's: run `rico -l' and see the list of commands. > I think it would be more useful to keep separate commands and just > have them all start with the same prefix to make them easier to > find. [...] Well chosen names with a common prefix go a long way A good case study of the multiple-commands-with-common-prefix is git, which (IIUC) started with that but since there are way too many commands they switched *to* `git subcommand', which runs `git-subcommand' from it's binary directory. IMO, that counts for a large experiment in the multiple-commands and a strong indicator that subcommands work out better. > This is is fact what svn does for all its svnadmin, svnsync, etc., > commands. I type 'svn' in my shell followed by two tabs and I get: > > svn svnlook > svn-populate-node-origins-index svnmucc > svnadmin svnserve > svnauthz-validate svnsync > svndumpfilter svnversion svn is not a good example -- they have a number of factors that makes it a different case: * They keep a strict set of commands, in particular, it's not user-extensible. * This means that extensions *must* be their own executables. [I ran into this when I tried to make it easier to do our workflow (when we switched from cvs) -- the way I did it was to replace `svn' with a (mzscheme) script (that you'd put higher in your $PATH) that passes everything to the `svn' command except for some plt-specific commands that would be intercepted.] * Some of these things serve completely different purposes, for example, `svnserve' is meant to run from an /etc/xinetd.d script, `svnlook' is guaranteed to be read-only and therefore safe for use in post-commit hooks. The bottom line from their POV is that as a user you need to use only svn. > Neil Van Dyke wrote: > > I think that ".racket-source" would be an annoyingly long filename > > extension for many people who would use Racket. > > I'll second that. Using tab-completion only works if the file > already exists. Long extension names are also a pain when listing > files in a shell because it reduces the number of columns and makes > the listing needlessly long. So, as far as I'm concerned, the > shorter the better. > > And while we're at it, I'd vote for a short extension name that's > also easy to type on a keyboard (because something like 'scrbl' > isn't exactly easy on the fingers...) :-) [+1, but I'll post another message.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev