small doc fixes, plus change to syntax pattern matching to allow null as a dotted match after ellipses
svn: r8384
This commit is contained in:
parent
b7a19fdc4a
commit
b2dbe63ed1
|
@ -44,6 +44,7 @@
|
|||
(define (formals->list formals)
|
||||
(syntax-case formals ()
|
||||
[(formal ... . rest)
|
||||
(not (null? (syntax-e #'rest)))
|
||||
;; dot is exactly like #:rest, but don't allow it with other
|
||||
;; meta-keywords since its meaning is confusing
|
||||
(let* ([formals (syntax->list #'(formal ...))]
|
||||
|
|
|
@ -130,6 +130,7 @@
|
|||
(with-syntax ([(pats* ...) (syntax-map simplify/i #'(pats ...))])
|
||||
(syntax/loc stx (kw pats* ...)))]
|
||||
[(kw pats ... . rest)
|
||||
(not (null? (syntax-e #'rest)))
|
||||
(match:syntax-err stx (format "~a pattern must have a proper list of subpatterns" (syntax-e #'kw)))]
|
||||
|
||||
;; hash table patterns have their own syntax
|
||||
|
|
|
@ -97,31 +97,31 @@ improve method arity mismatch contract violation error messages?
|
|||
;; In an expression context:
|
||||
(let ([key (syntax-local-lift-context)])
|
||||
;; Already lifted in this lifting context?
|
||||
(unless (hash-table-get saved-id-table key #f)
|
||||
;; No: lift the contract creation:
|
||||
(with-syntax ([contract-id contract-id]
|
||||
[id id]
|
||||
[name (datum->syntax #f (syntax->datum id) id)]
|
||||
[pos-module-source pos-module-source])
|
||||
(hash-table-put!
|
||||
saved-id-table
|
||||
key
|
||||
(syntax-local-introduce
|
||||
(syntax-local-lift-expression
|
||||
#'(-contract contract-id
|
||||
id
|
||||
pos-module-source
|
||||
(module-source-as-symbol #'name)
|
||||
(quote-syntax name)))))))
|
||||
;; Expand to a use of the lifted expression:
|
||||
(with-syntax ([saved-id (syntax-local-introduce (hash-table-get saved-id-table key))])
|
||||
(syntax-case stx (set!)
|
||||
[name
|
||||
(identifier? (syntax name))
|
||||
(syntax saved-id)]
|
||||
[(name . more)
|
||||
(with-syntax ([app (datum->syntax stx '#%app)])
|
||||
(syntax/loc stx (app saved-id . more)))])))
|
||||
(let ([lifted-id
|
||||
(or (hash-table-get saved-id-table key #f)
|
||||
;; No: lift the contract creation:
|
||||
(with-syntax ([contract-id contract-id]
|
||||
[id id]
|
||||
[name (datum->syntax #f (syntax->datum id) id)]
|
||||
[pos-module-source pos-module-source])
|
||||
(syntax-local-introduce
|
||||
(syntax-local-lift-expression
|
||||
#'(-contract contract-id
|
||||
id
|
||||
pos-module-source
|
||||
(module-source-as-symbol #'name)
|
||||
(quote-syntax name))))))])
|
||||
(when key
|
||||
(hash-table-put! saved-id-table key lifted-id))
|
||||
;; Expand to a use of the lifted expression:
|
||||
(with-syntax ([saved-id (syntax-local-introduce lifted-id)])
|
||||
(syntax-case stx (set!)
|
||||
[name
|
||||
(identifier? (syntax name))
|
||||
(syntax saved-id)]
|
||||
[(name . more)
|
||||
(with-syntax ([app (datum->syntax stx '#%app)])
|
||||
(syntax/loc stx (app saved-id . more)))]))))
|
||||
;; In case of partial expansion for module-level and internal-defn contexts,
|
||||
;; delay expansion until it's a good time to lift expressions:
|
||||
(quasisyntax/loc stx (#%expression #,stx)))))))
|
||||
|
|
|
@ -178,9 +178,7 @@
|
|||
(if (stx-null? s)
|
||||
0
|
||||
-inf.0)
|
||||
(if (stx-null? s)
|
||||
-inf.0
|
||||
1)))))])
|
||||
1))))])
|
||||
(loop s))])
|
||||
(values pre post (= m n)))))
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ value of @scheme[x] has been incremented (and the change is visible
|
|||
inside the module @scheme[x]).
|
||||
|
||||
To work around this, export accessor functions, rather than
|
||||
exporting the function directly, like this:
|
||||
exporting the variable directly, like this:
|
||||
|
||||
@schememod[
|
||||
scheme
|
||||
|
|
|
@ -247,7 +247,7 @@ scheme
|
|||
]
|
||||
|
||||
In general, each use of @scheme[node/dc] must name the
|
||||
fields and then specify contracts for each fields. In the
|
||||
fields and then specify contracts for each field. In the
|
||||
above, the @scheme[val] field is a contract that accepts
|
||||
values between @scheme[low] and @scheme[high].
|
||||
The @scheme[left] and @scheme[right] fields are
|
||||
|
|
|
@ -304,7 +304,7 @@ The @scheme[define-serializable-struct] form defines a structure type
|
|||
that can be @scheme[serialize]d to a value that can be printed using
|
||||
@scheme[write] and restored via @scheme[read]. The @scheme[serialize]d
|
||||
result can be @scheme[deserialize]d to get back an instance of the
|
||||
original structure type. The serialization form an functions are
|
||||
original structure type. The serialization form and functions are
|
||||
provided by the @schememodname[scheme/serialize] library.
|
||||
|
||||
@examples[
|
||||
|
|
|
@ -43,7 +43,7 @@ evaluation is reflective. Execution starts with an initial namespace
|
|||
that contains a few primitive modules, and that is further populated
|
||||
by loading files and modules as specified on the command line or as
|
||||
supplied in the @tech{REPL}. Top-level @scheme[require] and
|
||||
@scheme[define] forms adjust the identifier mapping, and module
|
||||
@scheme[define] forms adjusts the identifier mapping, and module
|
||||
declarations (typically loaded on demand for a @scheme[require] form)
|
||||
adjust the module mapping.
|
||||
|
||||
|
@ -106,7 +106,7 @@ get started:
|
|||
]
|
||||
|
||||
Note that the @scheme[parameterize] of @scheme[current-namespace] does
|
||||
not affect the meaning of identifier like @scheme[namespace-require]
|
||||
not affect the meaning of identifiers like @scheme[namespace-require]
|
||||
within the @scheme[parameterize] body. Those identifiers obtain their
|
||||
meaning from the enclosing context (probably a module). Only
|
||||
expressions that are dynamic with respect to this code, such as the
|
||||
|
|
|
@ -35,8 +35,8 @@ usual binding, the expression @scheme[(let ([x 1][y (lambda () 4)]) (+
|
|||
1 (y)))] is compiled the same as the constant @scheme[5].
|
||||
|
||||
On some platforms, bytecode is further compiled to native code via a
|
||||
@deftech{jut-in-time} or @deftech{JIT} compiler. The @tech{JIT}
|
||||
compiler substantially speed programs that execute tight loops,
|
||||
@deftech{just-in-time} or @deftech{JIT} compiler. The @tech{JIT}
|
||||
compiler substantially speeds programs that execute tight loops,
|
||||
arithmetic on small integers, and arithmetic on inexact real
|
||||
numbers. Currently, @tech{JIT} compilation is supported for x86,
|
||||
x86_64 (a.k.a. AMD64), and 32-bit PowerPC processors. The @tech{JIT}
|
||||
|
@ -59,7 +59,7 @@ difficult to detect.
|
|||
The module system aids optimization by helping to ensure that
|
||||
identifiers have the usual bindings. That is, the @scheme[+] provided
|
||||
by @schememodname[scheme/base] can be recognized by the compiler and
|
||||
inlined, which is especially imported for @tech{JIT}-compiled code.
|
||||
inlined, which is especially important for @tech{JIT}-compiled code.
|
||||
In contrast, in a traditional interactive Scheme system, the top-level
|
||||
@scheme[+] binding might be redefined, so the compiler cannot assume a
|
||||
fixed @scheme[+] binding (unless special flags or declarations
|
||||
|
@ -82,7 +82,7 @@ definitions when interactive exploration is more important. See
|
|||
@secref["module-set"] for more information.
|
||||
|
||||
Currently, the compiler does not attempt to inline or propagate
|
||||
constant across module boundary, except for exports of the built-in
|
||||
constants across module boundary, except for exports of the built-in
|
||||
modules (such as the one that originally provides @scheme[+]).
|
||||
|
||||
The later section @secref["letrec-performance"] provides some
|
||||
|
|
|
@ -105,7 +105,7 @@ A syntax object matches a @scheme[pattern] as follows:
|
|||
Like the previous kind of pattern, but with a final
|
||||
sub-@scheme[pattern] as for @scheme[(pattern ...+ . pattern)]. The
|
||||
final @scheme[pattern] never matches a syntax object whose datum is a
|
||||
list.}
|
||||
pair.}
|
||||
|
||||
@specsubform[(code:line #,(tt "#")(pattern ...))]{
|
||||
|
||||
|
|
|
@ -203,17 +203,17 @@ it is not @scheme[#f], otherwise the path is left relative).}
|
|||
|
||||
|
||||
@defproc*[([(port-write-handler [out output-port?]) (any/c output-port? . -> . any)]
|
||||
[(port-write-handler [in input-port?]
|
||||
[(port-write-handler [out output-port?]
|
||||
[proc (any/c output-port? . -> . any)])
|
||||
void?])]{}
|
||||
|
||||
@defproc*[([(port-display-handler [out output-port?]) (any/c output-port? . -> . any)]
|
||||
[(port-display-handler [in input-port?]
|
||||
[proc (any/c output-port? . -> . any)])
|
||||
[(port-display-handler [out output-port?]
|
||||
[proc (any/c output-port? . -> . any)])
|
||||
void?])]{}
|
||||
|
||||
@defproc*[([(port-print-handler [out output-port?]) (any/c output-port? . -> . any)]
|
||||
[(port-print-handler [in input-port?]
|
||||
[(port-print-handler [out output-port?]
|
||||
[proc (any/c output-port? . -> . any)])
|
||||
void?])]{
|
||||
|
||||
|
|
|
@ -481,7 +481,9 @@ a @scheme[slide] sequence.}
|
|||
|
||||
Evaluates the @scheme[body]s once for each @scheme[id], skipping an
|
||||
@scheme[id] if its name ends with @litchar{~} and @scheme[condense?]
|
||||
is true.
|
||||
is true. The results of the last @scheme[body] for each iteration are
|
||||
collected into a list, which is the result of the @scheme[with-steps]
|
||||
form.
|
||||
|
||||
Within the @scheme[body]s, several keywords are bound non-hygienically
|
||||
(using the first @scheme[body]'s lexical context):
|
||||
|
|
|
@ -48,7 +48,9 @@
|
|||
(define-syntax sd (syntax-rules () [(_ v) (syntax->datum (syntax v))]))
|
||||
|
||||
(test '(3 1 2) 'syntax-case (syntax-case '(1 2 3) () [(a ... b) (sd (b a ...))]))
|
||||
(test 5 'syntax-case (syntax-case '(1 2 3) () [(a ... b . c) (sd (b a ... c))][_else 5]))
|
||||
(test '(3 1 2) 'syntax-case (syntax-case '(1 2 3) () [(a ... b . c) (sd (b a ...))]))
|
||||
(test '(3 1 2) 'syntax-case (syntax-case '(1 2 3) () [(a ... 3 . c) (sd (3 a ...))]))
|
||||
(test 5 'syntax-case (syntax-case '(1 2 3 4) () [(a ... 3 . c) (sd (3 a ... c))][_else 5]))
|
||||
(test '(3 1 2 4) 'syntax-case (syntax-case '(1 2 3 . 4) () [(a ... b . c) (sd (b a ... c))][_else 5]))
|
||||
(test '(3 1 2 4) 'syntax-case (syntax-case '(1 2 (3 . 4)) () [(a ... (b . c)) (sd (b a ... c))][_else 5]))
|
||||
(test '((3) 1 2 4) 'syntax-case (syntax-case '(1 2 (3 . 4)) () [(a ... (b ... . c)) (sd ((b ...) a ... c))][_else 5]))
|
||||
|
@ -956,7 +958,7 @@
|
|||
#'(list lifted-output id))]))
|
||||
|
||||
(test 2 '@@foo (@@foo 2))
|
||||
(test #t values prev-ctx)
|
||||
(test #f values prev-ctx)
|
||||
(test 2 eval (expand-once #'(@@foo 2)))
|
||||
(test 2 eval (expand #'(@@foo 2)))
|
||||
(test 2 eval (expand-to-top-form #'(@@foo 2)))
|
||||
|
|
Loading…
Reference in New Issue
Block a user