[plt-dev] renaming programs in the distribution
Does this lessen the strangeness of the mzscheme commandline switches
by moving some of them into subcommands in racket?
Should : be a special character that indicates a filename so that
things like "racket c:foo" load a file?
Robby
PS: I'm surprised to be writing this, but I'm slightly saddened to see
'rico' go :).
On Tue, Apr 20, 2010 at 2:27 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> In trying to balance all of the naming issues, I'm coming around to the
> idea that `racket' can work both as the command tool as the program
> runner. [For the record, Eli tried to convince me of that long ago.]
>
>
> The rationale:
>
> We want everything to be "Racket" (not "PLT" and not something
> close-but-not-too-close like "rico") and we want a tool to group
> commands (because the `git' experience seems definitive). With those
> two constraints, giving `racket' the tool-launching job seems like the
> only solution. At the same time, we'd really prefer `racket' to provide
> a REPL and/or start a program.
>
>
> Some supporting experience:
>
> In the v4.0-series PLT Scheme, the `mzscheme' command-line syntax
> stands out for its irregular and complex rules --- especially
> considering that it was designed that way on purpose.
>
> For example, `mzscheme -i -l scheme/base' means something completely
> different than `mzscheme -l scheme/base -i'. Also, `mzscheme -l
> scheme/base' means yet something else, despite the fact that `mzscheme'
> and `mzscheme -i' are equivalent.
>
> The complex rules let the `mzscheme' binary serve many roles: starting
> a REPL, running a program, following a `#!' at the start of a Unix
> script, and starting a REPL for a particular language. It's a kind of
> complexity that gives the illusion of simplicity, because you just use
> `mzscheme' to do lots of things.
>
> Maybe the same kind of complexity works out for giving `racket' one
> more job.
>
>
> A proposal:
>
> If you run
>
> racket <command> ....
>
> where <command> doesn't have a "/", "\", or "." in it, then it's a
> command dispatch. Any other use of `racket' could be like the current
> `racket' command line.
>
> [Yes, weird and ugly. It's the sort of ad hoc rule that we'd
> normally flag as poor language design. But if it works out, then
> we'll get over it.]
>
> This rule works for scripts that start
>
> #! racket
>
> because the script name will be passed to `racket' as a full path,
> which must at least have a "/". It will also work for common uses such
> as
>
> racket x.rkt
>
> since programs that you pass to racket tend to have a suffix on them.
> If your file doesn't have a suffix, then you'll be forced to either use
> the `run' command:
>
> racket run myprog
>
> or tack a "./" (or ".\" under Windows) on the front:
>
> racket ./myprog
>
> When you run just `racket' and get a REPL, something in the banner
> should tell you to try `racket help' for information on other commands.
>
>
> Following through with the remaining names:
>
> If we go that route --- and I think it's worth a try --- that leaves us
> with the problem of naming programs that currently start with "PLT".
>
> My preference is still to turn `plt-web-server' into `racket
> web-server', because the point of starting the web server is ultimately
> to run some Racket code that you wrote. (Along the same lines, I think
> it makes sense to add `scribble' and `slideshow' commands.) Giving the
> web server some non-generic name seems ok, too. Changing
> `plt-web-server' to `racket-web-server' seems awkward to me, because it
> would be the only important command that starts `racket' but uses a
> hyphen instead of a space.
>
> The "PLT Games" executable doesn't fit anywhere, and maybe it's not
> crucial that it has "Racket" in its name. Leaving it as "PLT Games"
> could be ok.
>
> Finally, just leave `plt-r5rs' and `plt-r6rs' alone, since we need to
> keep those names for backward compatibility, anyway.
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-dev
>