Produces the same result as
expr. Using
#%expression forces the parsing of a form as an
expression.
Examples:
eval:8:0: define: not allowed in an expression context
The
#%expression form is helpful in recursive definition contexts
where expanding a subsequent definition can provide compile-time information
for the current expression. For example, consider a
define-sym-case
macro that simply records some symbols at compile-time in a given identifier.
and then a variant of
case that checks to make sure the symbols
used in the expression match those given in the earlier definition:
[(_ id val-expr[(sym)expr]... ) 'sym-case
"expected an identifier bound via define-sym-case"
stx
'sym-case
(format "expected the symbols ~s" expected-ids)
stx))
#'(case val-expr[(sym)expr]... ))]))
If the definition follows the use like this, then
the
define-sym-case macro does not have
a chance to bind
id and the
sym-case
macro signals an error:
(sym-caseland-creatures'bear
[(bear)1]
[(fox)2])
(define-sym-caseland-creaturesbearfox))
eval:11:0: sym-case: expected an identifier bound via
in: (sym-case land-creatures (quote bear) ((bear) 1)
But if the
sym-case is wrapped in an
#%expression ,
then the expander does not need to expand it to know it is
an expression and it moves on to the
define-sym-case
expression.
[(whale)1]
[(squid)2]))
(define-sym-casesea-creatureswhalesquid)
'more...)
Of course, a macro like
sym-case should not require its
clients to add
#%expression ; instead it should check
the basic shape of its arguments and then expand to
#%expression
wrapped around a helper macro that calls
syntax-local-value
and finishes the expansion.