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. -Philip -- 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.
