On Wed, May 16, 2018 at 4:09 PM, Neil Van Dyke <n...@neilvandyke.org> wrote:

> Sam answered your question.  Here's how one can usually answer the more
> general question...
> * The documentation for most Racket modules will usually say what
> `require` form you need to import it, assuming that you are using the
> `racket/base` language.  For example, if you're looking at the
> documentation for `make-temporary-file` in your Web browser, such as with
> the URL:
> https://docs.racket-lang.org/reference/Filesystem.html#(def.
> _((lib._racket%2Ffile..rkt)._make-temporary-file))

In addition to what Neil said, if you hover over "make-temporary-file" in
the blue box, your browser will show a tooltip saying, "Provided from:
racket/file, racket | Package: base", which tells you the same information
as scrolling up without any question as to which section/page of the
documentation has the information on what library the identifier comes from.

> (BTW, for "professional quality" purposes, one should normally use `#lang
> racket/base`, just as in the example you gave, rather than use `#lang
> racket`.  `#lang racket` is for quick throwaway code or for illustrating
> examples, when you don't want to bother saying `require` much, and don't
> mind that it adds dependencies on a lot of modules that you probably don't
> need.)

At the risk of getting slightly off-topic, my perspective on this has been
evolving somewhat. The main advantage of `#lang racket/base` is startup
time (because you avoid loading unneeded libraries), so you definitely want
to use it when you care about that, or when you're writing a reusable
library, since someone who cares about startup time might want to use it.
(Maybe this is what you meant, Neil, by "professional quality".) But there
is good tooling support for taking a module written in `#lang racket` and
refactoring it to use `#lang racket/base`—running `raco check-requires -b
my-module.rkt` will tell you exactly what modules you actually need to
require—so even in those cases I often use `#lang racket` for the initial
stages of development.

Perhaps more controversially, I've also found that, for many things I
write, I find the startup time of `#lang racket` acceptable. As a matter of
style, I like that using `#lang racket` avoids cluttering up my `require`
statement with the same usual things (`racket/contract`, `racket/match`,
`racket/list`, `racket/string`, `(for-syntax racket/base)`, etc.), making
it more obvious what the important dependencies of a given module actually
are. (Of course, another way to do that is to define your own #lang for the
implementation of a given project that provides those common dependencies,
but only the ones you actually need.)

Most topically, I recommend `#lang racket` for beginners: there's plenty to
learn about Racket, and optimizing your `require` statement is probably
something you can ignore for a while.


You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to