A bunch of typo fixes from Richard Cleis.
This commit is contained in:
parent
c4613cf9ab
commit
a7064d5f6a
|
@ -139,10 +139,10 @@ calculation.}
|
|||
@defproc[(gradient [f (real? real? . -> . real?)] [h real? .000001])
|
||||
((vector/c real? real?) . -> . (vector/c real? real?))]{
|
||||
|
||||
Creates a vector-valued function that the numeric gradient of
|
||||
Creates a vector-valued function that computes the numeric gradient of
|
||||
@racket[f].}
|
||||
|
||||
@defproc[(make-vec [fx (real? real? . -> . real?)] [fy (real? real? . -> . real?)])
|
||||
((vector/c real? real?) . -> . (vector/c real? real?))]{
|
||||
|
||||
Creates a vector-values function from two parts.}
|
||||
Creates a vector-valued function from two parts.}
|
||||
|
|
|
@ -161,7 +161,7 @@ the name @racket["example-suite"]:
|
|||
]
|
||||
|
||||
@defform[(define/provide-test-suite name test ...)]{ This
|
||||
for is just like @racket[define-test-suite], and in addition
|
||||
form is just like @racket[define-test-suite], and in addition
|
||||
it @racket[provide]s the test suite.}
|
||||
|
||||
@;{
|
||||
|
@ -177,4 +177,3 @@ body expressions.
|
|||
As far I know no-one uses this macro, so it might disappear
|
||||
in future versions of RackUnit.}
|
||||
}
|
||||
|
||||
|
|
|
@ -297,7 +297,7 @@ and make them more accessible to potential clients.
|
|||
|
||||
Going back to the bank-account example, suppose that we generalize the
|
||||
module to support multiple accounts and that we also include a
|
||||
withdrawal operation. The improved bank-account module includes a
|
||||
withdrawal operation. The improved bank-account module includes an
|
||||
@racket[account] structure type and the following functions:
|
||||
|
||||
@racketblock[
|
||||
|
|
|
@ -59,14 +59,14 @@ Specifically,
|
|||
the @racket[null?] predicate (and many other predicates) return @racket[#f]
|
||||
for @racket[#:∃] contracts, and changing one of those contracts to @racket[any/c]
|
||||
means that @racket[null?] might now return @racket[#t] instead, resulting in
|
||||
arbitrarily different behavior depending on this boolean might flow around
|
||||
arbitrarily different behavior depending on how this boolean might flow around
|
||||
in the program.
|
||||
|
||||
@defmodulelang[racket/exists]
|
||||
|
||||
To work around the above problem, the
|
||||
@racketmodname[racket/exists] library behaves just like the @racketmodname[racket],
|
||||
but where predicates signal errors when given @racket[#:∃] contracts.
|
||||
@racketmodname[racket/exists] library behaves just like @racketmodname[racket],
|
||||
but predicates signal errors when given @racket[#:∃] contracts.
|
||||
|
||||
Moral: Do not use predicates on @racket[#:∃] contracts, but if you're not sure, use
|
||||
@racketmodname[racket/exists] to be safe.
|
||||
|
@ -90,7 +90,7 @@ streams like this:
|
|||
|
||||
Unfortunately, this does not work because the value of
|
||||
@racket[stream/c] is needed before it is defined. Put another way, all
|
||||
of the combinators evaluate their arguments eagerly, even thought the
|
||||
of the combinators evaluate their arguments eagerly, even though the
|
||||
values that they accept do not.
|
||||
|
||||
Instead, use
|
||||
|
|
|
@ -124,7 +124,7 @@ that the function produces a single value. That is,
|
|||
|
||||
@racketblock[(-> integer? any)]
|
||||
|
||||
describes a function that accepts and integer and returns any number of
|
||||
describes a function that accepts an integer and returns any number of
|
||||
values, while
|
||||
|
||||
@racketblock[(-> integer? any/c)]
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
#lang scribble/base
|
||||
@(require scribble/manual
|
||||
@(require scribble/manual
|
||||
"guide-utils.rkt")
|
||||
|
||||
@title[#:tag "dialects" #:style 'toc]{Dialects of Racket and Scheme}
|
||||
|
||||
We use ``Racket'' to refer to a specific dialect of the Lisp language,
|
||||
and one that is based on the Scheme branch of the Lisp family.
|
||||
Despite Racket's similarly to Scheme, the @hash-lang[] prefix on
|
||||
Despite Racket's similarity to Scheme, the @hash-lang[] prefix on
|
||||
modules is a particular feature of Racket, and programs that start
|
||||
with @hash-lang[] are unlikely to run in other implementations of
|
||||
Scheme. At the same time, programs that do not start with @hash-lang[]
|
||||
|
|
|
@ -393,7 +393,7 @@ multiple identifiers, @racket[for] can bind multiple sequence elements
|
|||
to multiple iteration identifiers:
|
||||
|
||||
@margin-note{While @racket[let] must be changed to @racket[let-values]
|
||||
to bind multiple identifier, @racket[for] simply allows a
|
||||
to bind multiple identifiers, @racket[for] simply allows a
|
||||
parenthesized list of identifiers instead of a single
|
||||
identifier in any clause.}
|
||||
|
||||
|
|
|
@ -148,7 +148,7 @@ While the @racket[_expr]s of a @racket[letrec] form are typically
|
|||
expressions are evaluated in order, and after each value is obtained,
|
||||
it is immediately associated with its corresponding @racket[_id]. If
|
||||
an @racket[_id] is referenced before its value is ready, the result is
|
||||
@|undefined-const|, as just as for internal definitions.
|
||||
@|undefined-const|, just as for internal definitions.
|
||||
|
||||
@interaction[
|
||||
(letrec ([quicksand quicksand])
|
||||
|
|
|
@ -214,7 +214,7 @@ sense. In that case, you have two options:
|
|||
unquoted path, just like libraries that are included with the
|
||||
Racket distribution.}
|
||||
|
||||
@item{Add the library a new or existing @|PLaneT| package. Libraries
|
||||
@item{Add the library to a new or existing @|PLaneT| package. Libraries
|
||||
in a @|PLaneT| package are referenced with a path of the form
|
||||
@racket[(planet ....)] path.
|
||||
@margin-note*{See @other-doc['(lib "planet/planet.scrbl")]
|
||||
|
@ -269,7 +269,7 @@ top-level name like @filepath{molly} that identifies the producer.
|
|||
Use a collection name like @filepath{bakery} when producing the
|
||||
definitive collection of baked-goods libraries.
|
||||
|
||||
After your libraries are in a @tech{collection}, then you can still
|
||||
After your libraries are put in a @tech{collection} you can still
|
||||
use @exec{raco make} to compile the library sources, but it's better
|
||||
and more convenient to use @exec{raco setup}. The @exec{raco setup}
|
||||
command takes a collection name (as opposed to a file name) and
|
||||
|
|
|
@ -8,7 +8,7 @@ same syntactic keyword @racket[let] as for local binding, but an
|
|||
identifier after the @racket[let] (instead of an immediate open
|
||||
parenthesis) triggers a different parsing.
|
||||
|
||||
@specform[
|
||||
@racketblock[
|
||||
(let _proc-id ([_arg-id _init-expr] ...)
|
||||
_body ...+)
|
||||
]
|
||||
|
|
|
@ -362,24 +362,24 @@ above, we'll generate
|
|||
and redirect a function call @racket[(f x y)] to
|
||||
|
||||
@racketblock[
|
||||
(do-f (lambda () x)
|
||||
(do-f (lambda () x)
|
||||
(lambda () y)
|
||||
(lambda (v) (set! x v))
|
||||
(lambda (v) (set! x v))
|
||||
(lambda (v) (set! y v)))
|
||||
]
|
||||
|
||||
Clearly, then @racket[define-cbr] is a macro-generating macro, which
|
||||
binds @racket[f] to a macro that expands to a call of @racket[do-f].
|
||||
That is, @racket[(define-cbr (f a b) (swap ab))] needs to generate the
|
||||
That is, @racket[(define-cbr (f a b) (swap a b))] needs to generate the
|
||||
definition
|
||||
|
||||
@racketblock[
|
||||
(define-syntax f
|
||||
(syntax-rules ()
|
||||
[(id actual ...)
|
||||
(do-f (lambda () actual)
|
||||
(do-f (lambda () actual)
|
||||
...
|
||||
(lambda (v)
|
||||
(lambda (v)
|
||||
(set! actual v))
|
||||
...)]))
|
||||
]
|
||||
|
@ -415,7 +415,7 @@ converts
|
|||
|
||||
to the function definition @racket[do-f] above. Most of the work is
|
||||
generating a @racket[define-get/put-id] declaration for each argument,
|
||||
@racket[a] ad @racket[b], and putting them before the body. Normally,
|
||||
@racket[a] and @racket[b], and putting them before the body. Normally,
|
||||
that's an easy task for @racket[...] in a pattern and template, but
|
||||
this time there's a catch: we need to generate the names
|
||||
@racket[get-a] and @racket[put-a!] as well as @racket[get-b] and
|
||||
|
|
|
@ -30,7 +30,7 @@ procedure:
|
|||
|
||||
Instead of using @racket[syntax-rules], you can write your own macro
|
||||
transformer procedure directly using @racket[lambda]. The argument to
|
||||
the procedure is a values that represents the source form, and the
|
||||
the procedure is a value that represents the source form, and the
|
||||
result of the procedure must be a value that represents the
|
||||
replacement form.
|
||||
|
||||
|
|
|
@ -165,7 +165,7 @@ specifications in terms of a character, a type of mapping for the
|
|||
character, and (for certain types of mappings) a parsing
|
||||
procedure. For example, to extend the readtable so that @litchar{$}
|
||||
can be used to start and end infix expressions, implement a
|
||||
@racket[parse-dollar] function and use:
|
||||
@racket[read-dollar] function and use:
|
||||
|
||||
@racketblock[
|
||||
(make-readtable (current-readtable)
|
||||
|
@ -182,9 +182,9 @@ additional arguments that provide the source location of the
|
|||
character.
|
||||
|
||||
The following @filepath{dollar.rkt} module defines a
|
||||
@racket[parse-dollar] function in terms of the @racketidfont{read} and
|
||||
@racket[read-dollar] function in terms of the @racketidfont{read} and
|
||||
@racketidfont{read-syntax} functions provided by @filepath{arith.rkt},
|
||||
and it puts @racket[parse-dollar] together with new @racketidfont{read} and
|
||||
and it puts @racket[read-dollar] together with new @racketidfont{read} and
|
||||
@racketidfont{read-syntax} functions that install the readtable and
|
||||
chain to Racket's @racket[read] or @racket[read-syntax]:
|
||||
|
||||
|
|
|
@ -557,7 +557,7 @@ refer back to an already matched subpattern in the pattern.
|
|||
@litchar{\}@math{n} stands for an exact repeat of the @math{n}th
|
||||
submatch. Note that @litchar{\0}, which is useful in an insert string,
|
||||
makes no sense within the regexp pattern, because the entire regexp
|
||||
has not matched yet that you could refer back to it.}
|
||||
has not matched yet so you cannot refer back to it.}
|
||||
|
||||
@interaction[
|
||||
(regexp-match #px"([a-z]+) and \\1"
|
||||
|
|
|
@ -60,7 +60,7 @@ with a @deftech{dye pack}. When a syntax object is armed, then
|
|||
@racket[syntax-e] taints any syntax object in its result. Similarly,
|
||||
@racket[datum->syntax] taints its result when its first argument is
|
||||
armed. Finally, if any part of a quoted syntax object is armed, then
|
||||
the corresponding part is tainted the resulting syntax constant.
|
||||
the corresponding part taints the resulting syntax constant.
|
||||
|
||||
Of course, the macro expander itself must be able to @deftech{disarm}
|
||||
a taint on a syntax object, so that it can further expand an
|
||||
|
|
|
@ -81,7 +81,7 @@ is itself a list, then no quote mark is printed for the inner list:
|
|||
]
|
||||
|
||||
For nested lists, especially, the @racket[quote] form lets you write a
|
||||
list as an expression in essentially the same way that the list it
|
||||
list as an expression in essentially the same way that the list
|
||||
prints:
|
||||
|
||||
@interaction[
|
||||
|
|
|
@ -589,12 +589,12 @@ As a form for modularity, @racket[unit] complements @racket[module]:
|
|||
@racketmodname[racket/base]---the one that extracts the first
|
||||
element of an instance of the built-in pair datatype---as
|
||||
opposed to any number of other functions with the name
|
||||
@racket[car]. In other word, the @racket[module] construct lets
|
||||
@racket[car]. In other words, the @racket[module] construct lets
|
||||
you refer to @emph{the} binding that you want.}
|
||||
|
||||
@item{The @racket[unit] form is for parameterizing a code fragment
|
||||
with respect to most any kind of run-time value. For example,
|
||||
it allows a code fragment for work with a @racket[car]
|
||||
it allows a code fragment to work with a @racket[car]
|
||||
function that accepts a single argument, where the specific
|
||||
function is determined later by linking the fragment to
|
||||
another. In other words, the @racket[unit] construct lets you
|
||||
|
|
|
@ -502,7 +502,7 @@ both @racket[y] and @racket[x] are @tech{variables}. The @racket[y]
|
|||
a @tech{local variable}. When this code is evaluated, a
|
||||
@tech{location} is created for @racket[x] to hold the value
|
||||
@racket[5], and a @tech{location} is also created for @racket[y] to
|
||||
hold the value @racket[6].
|
||||
hold the value @racket[11].
|
||||
|
||||
The replacement of a @tech{variable} with a @tech{location} during
|
||||
evaluation implements Racket's @deftech{lexical scoping}. For example,
|
||||
|
|
|
@ -2544,7 +2544,7 @@ by @racket[make-rename-transformer] or as an instance of a structure
|
|||
type with the @racket[prop:rename-transformer] property, then this
|
||||
form is expanded by replacing @racket[id] with the target identifier
|
||||
(e.g., the one provided to @racket[make-rename-transformer]). If a
|
||||
transformer binding has both @racket[prop:set!-transformer] ad
|
||||
transformer binding has both @racket[prop:set!-transformer] and
|
||||
@racket[prop:rename-transformer] properties, the latter takes
|
||||
precedence.
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user