[racket] changing the default language

On Aug 25, Kartik Agaram wrote:
> > * If you're talking about running racket, then you can use a flag
> >   to set the initial language: "racket -I mzscheme".
> 
> '$ racket -l mzscheme -f main.scm' turns out to be just what I
> wanted. Thanks!

(And you know that using `load' (which is what "-f" does) is almost
always a bad idea, right?)


> But it's counterintuitive that this doesn't work:
> 
>   $ racket -f main.scm -l mzscheme
>   main.scm:1:10: #%app: missing procedure expression; probably
> originally (), which is an illegal empty application in: (#%app)
> 
> What's the right mental model for this? Is the -l causing future files
> on the commandline to be in the requested language?

The "-f" flag specifies a file to `load'; loading a file is basically
reading its contents and `eval'uating it; by default, racket starts
with an *empty* namespace, it doesn't even have function application,
which is the complaint you see.

By using `-l mzscheme', you're requiring the `mzscheme' module into
this empty namespace, and after that loading the file works fine since
all that syntax is defined.  The order of the flags is meaningful,
which is why the `-l mzscheme' must be first.


> Are there online docs on the commandline flags online? racket --help
> says this about -l
> 
>   -l <path>, --lib <path> : Like -e '(require (lib "<path>"))'
> 
> Is this right?

Yes.  (And "Like" is there for a reason -- it's not really evaluating a
`require' form, since the initial namespace doesn't have that too...)


> >> Is there a way to switch the default language to mzscheme ...
> >> without getting into a module environment?
> >
> > * If you're talking about generating files, then you can just use
> >   "#lang mzscheme" at the top to get the (very) old legacy
> >   language.
> >
> > * And if you're talking about editing in DrRacket, then the
> >   language dialog has an "Automatic #lang line" that determines
> >   the line that gets inserted into new buffers.
> 
> #lang also turns each file into a module,

(Yes, and as a result it gets you in a saner world.)


> and I have to make sure I require files in the right order. With
> generated code this is often non-trivial.

If you make the generated files require each other properly, then you
don't need to require more than one file.  In most code generation
scenarios I have encountered, this is actually much easier to do than
to keep an ordered list of code to evaluate.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!