[racket-dev] Fwd: Racket startup

From: Eric Hanchrow (eric.hanchrow at gmail.com)
Date: Tue Jun 28 11:38:30 EDT 2011

---------- Forwarded message ----------
From: Eric Hanchrow <eric.hanchrow at gmail.com>
Date: Tue, Jun 28, 2011 at 8:34 AM
Subject: Re: [racket-dev] Racket startup
To: Eli Barzilay <eli at barzilay.org>


+100

I too go through the same dance as you.

On Tue, Jun 28, 2011 at 6:52 AM, Eli Barzilay <eli at barzilay.org> wrote:
> So this is my revised suggestion for the startup thing.  It's intended
> to resolve a few issues that bothered me for a while, and some new
> ones that were mentioned recently -- Jay's testing thing as well as
> the need for some way to write code that is run only when a file is
> executed directly.  I think that it works well *and* manages to mesh
> well with the current set of command-line flags, as well as being
> backward compatible.
>
> First, the thing that bugged me: `-m' is in theory a very convenient
> way to get some file into a generic script quickly, but it's not as
> convenient as it could be.  There are two problems with it -- in the
> many times that I used `-m', I think that in each and every case I
> went through the same dance that demonstrate them.  I start with a
> quick script, then realize that I want to make it a bit more generic
> -- so I wrap the toplevel code in a `main' definition.  Then, look
> through `racket -h' and figure out which flag I need to use -- I
> remember that `-m' by itself doesn't work, so I need to find out
> whether I need to make it `-tm' or `-um' or whatever.  once I find out
> the answer, I try to use it and then --always-- realize that I need to
> explicitly `provide' the `main' binding.  That's an annoyance I'd like
> to get rid of -- not only it is something that I always forget, it's a
> kind of a boilerplate in the spirit of `class main ... public static
> void whatever': it's providing a binding where I don't really want it
> to be provided for anything except for use by the `-m' flag.  (Yes,
> it's a *much* shorter and more pleasant boilerplate, but still it is
> one.)
>
> So here's my complete suggestion:
>
> 1. Add a `-R' or `--run' flag that takes in a name of a file and a
>   function to run.  Running `racket -R foo.rkt bar' does the same as
>   running `racket -u- foo.rkt', and after it is required, a `bar'
>   binding is pulled out from its namespace (no need to `provide' it),
>   and applied on the usual arguments (the name of the script and the
>   rest of the given flags).
>
> 1a. Probably better to make that `-R bar foo.rkt', so it's more
>    convenient to use in script trampolines with some "$@" input.
>
> 2. BTW, `-um- foo.rkt' would *not* be the same as `-R foo.rkt main',
>   because `-m' is disconnected from a specific module.  That makes it
>   still have some use as a more generic thing, but you pay for that
>   with the verbosity of an explicit `provide'.
>
> 3. Change the default of
>
>     If only configuration options are before the first argument, -u is added
>
>   to
>
>     If only configuration options are before the first argument, -R MAIN is added
>
>   possibly with some other name -- `MAIN' is just the first thing I
>   could think of that is not obnoxious for a command-line thing like
>   `#%main', and that will not lead to any problems with existing code.
>
> 4. Make `racket/base' provide `MAIN' that is just the same as `void'.
>   For compatibility, make `mzscheme' do the same too.
>
> This makes `MAIN' the Racket equivalent of Python's `__main__' thing.
> If you don't define it, things are pretty much the same as they are
> now.  If you do, then your binding overrides the built-in one, and you
> get a nice and convenient point for a "when this module is executed
> directly" thing.
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>



Posted on the dev mailing list.