[plt-dev] `rico' and ".rkt"

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!