guide: a few more typos in instantiations and visits sec

This commit is contained in:
Stephen Chang 2018-04-19 13:33:25 -04:00 committed by GitHub
parent 25fbaad1ad
commit 5de19e593b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -325,7 +325,7 @@ not yet specified what happens with @racket[for-meta 2] for when
If you think of the top-level as a kind of module that is continuously
expanded, the above rules imply that @racket[require] of another
module at the top level both instantiates and visits the other module
(it it is not already instantiated and visited). That's roughly true,
(if it is not already instantiated and visited). That's roughly true,
but the visit is made lazy in a way that is also explained in the next
section, @secref["stx-available-module"].
@ -343,14 +343,14 @@ A top-level @racket[require] of a module does not actually
@deftech{available}. An @tech{available} module will be @tech{visit}ed
when a future expression needs to be expanded in the same context. The
next expression may or may not involve some imported macro that needs
it's compile-time helpers evaluated by @tech{visit}ing, but the module
its compile-time helpers evaluated by @tech{visit}ing, but the module
system proactively @tech{visit}s the module, just in case.
In the following example, a random number is picked as a result of
visiting a module's own body while that module is being expanded. A
@racket[require] of the module instantiates it, printing ``running'',
and also makes the module @tech{available}. Evaluating any other
expression implies expanding the expression, and that expansions
expression implies expanding the expression, and that expansion
triggers a @tech{visit} of the @tech{available} module---which picks
another random number: