2 @node Procedures and Macros
3 @chapter Procedures and Macros
6 * Lambda:: Basic procedure creation using lambda.
7 * Optional Arguments:: Handling keyword, optional and rest arguments.
8 * Procedure Properties:: Procedure properties and meta-information.
9 * Procedures with Setters:: Procedures with setters.
10 * Macros:: Lisp style macro definitions.
11 * Syntax Rules:: Support for R5RS @code{syntax-rules}.
12 * Syntax Case:: Support for the @code{syntax-case} system.
13 * Internal Macros:: Guile's internal representation.
18 @section Lambda: Basic Procedure Creation
20 @c FIXME::martin: Review me!
22 A @code{lambda} expression evaluates to a procedure. The environment
23 which is in effect when a @code{lambda} expression is evaluated is
24 enclosed in the newly created procedure, this is referred to as a
25 @dfn{closure} (@pxref{About Closure}).
27 When a procedure created by @code{lambda} is called with some actual
28 arguments, the environment enclosed in the procedure is extended by
29 binding the variables named in the formal argument list to new locations
30 and storing the actual arguments into these locations. Then the body of
31 the @code{lambda} expression is evaluation sequentially. The result of
32 the last expression in the procedure body is then the result of the
35 The following examples will show how procedures can be created using
36 @code{lambda}, and what you can do with these procedures.
39 (lambda (x) (+ x x)) @result{} @r{a procedure}
40 ((lambda (x) (+ x x)) 4) @result{} 8
43 The fact that the environment in effect when creating a procedure is
44 enclosed in the procedure is shown with this example:
49 (lambda (y) (+ x y))))
54 @deffn syntax lambda formals body
55 @var{formals} should be a formal argument list as described in the
59 @item (@var{variable1} @dots{})
60 The procedure takes a fixed number of arguments; when the procedure is
61 called, the arguments will be stored into the newly created location for
64 The procedure takes any number of arguments; when the procedure is
65 called, the sequence of actual arguments will converted into a list and
66 stored into the newly created location for the formal variable.
67 @item (@var{variable1} @dots{} @var{variablen} . @var{variablen+1})
68 If a space-delimited period precedes the last variable, then the
69 procedure takes @var{n} or more variables where @var{n} is the number
70 of formal arguments before the period. There must be at least one
71 argument before the period. The first @var{n} actual arguments will be
72 stored into the newly allocated locations for the first @var{n} formal
73 arguments and the sequence of the remaining actual arguments is
74 converted into a list and the stored into the location for the last
75 formal argument. If there are exactly @var{n} actual arguments, the
76 empty list is stored into the location of the last formal argument.
79 @var{body} is a sequence of Scheme expressions which are evaluated in
80 order when the procedure is invoked.
84 @node Optional Arguments
85 @section Optional Arguments
87 @c FIXME::martin: Review me!
89 Scheme procedures, as defined in R5RS, can either handle a fixed number
90 of actual arguments, or a fixed number of actual arguments followed by
91 arbitrarily many additional arguments. Writing procedures of variable
92 arity can be useful, but unfortunately, the syntactic means for handling
93 argument lists of varying length is a bit inconvenient. It is possible
94 to give names to the fixed number of argument, but the remaining
95 (optional) arguments can be only referenced as a list of values
98 Guile comes with the module @code{(ice-9 optargs)}, which makes using
99 optional arguments much more convenient. In addition, this module
100 provides syntax for handling keywords in argument lists
103 Before using any of the procedures or macros defined in this section,
104 you have to load the module @code{(ice-9 optargs)} with the statement:
107 (use-modules (ice-9 optargs))
111 * let-optional Reference:: Locally binding optional arguments.
112 * let-keywords Reference:: Locally binding keywords arguments.
113 * lambda* Reference:: Creating advanced argument handling procedures.
114 * define* Reference:: Defining procedures and macros.
118 @node let-optional Reference
119 @subsection let-optional Reference
121 @c FIXME::martin: Review me!
123 The syntax @code{let-optional} and @code{let-optional*} are for
124 destructuring rest argument lists and giving names to the various list
125 elements. @code{let-optional} binds all variables simultaneously, while
126 @code{let-optional*} binds them sequentially, consistent with @code{let}
127 and @code{let*} (@pxref{Local Bindings}).
129 @deffn {library syntax} let-optional rest-arg (binding @dots{}) expr @dots{}
130 @deffnx {library syntax} let-optional* rest-arg (binding @dots{}) expr @dots{}
131 These two macros give you an optional argument interface that is very
132 @dfn{Schemey} and introduces no fancy syntax. They are compatible with
133 the scsh macros of the same name, but are slightly extended. Each of
134 @var{binding} may be of one of the forms @var{var} or @code{(@var{var}
135 @var{default-value})}. @var{rest-arg} should be the rest-argument of the
136 procedures these are used from. The items in @var{rest-arg} are
137 sequentially bound to the variable names are given. When @var{rest-arg}
138 runs out, the remaining vars are bound either to the default values or
139 left unbound if no default value was specified. @var{rest-arg} remains
140 bound to whatever may have been left of @var{rest-arg}.
142 After binding the variables, the expressions @var{expr} @dots{} are
147 @node let-keywords Reference
148 @subsection let-keywords Reference
150 @c FIXME::martin: Review me!
152 @code{let-keywords} and @code{let-keywords*} are used for extracting
153 values from argument lists which use keywords instead of argument
154 position for binding local variables to argument values.
156 @code{let-keywords} binds all variables simultaneously, while
157 @code{let-keywords*} binds them sequentially, consistent with @code{let}
158 and @code{let*} (@pxref{Local Bindings}).
160 @deffn {library syntax} let-keywords rest-arg allow-other-keys? (binding @dots{}) expr @dots{}
161 @deffnx {library syntax} let-keywords rest-arg allow-other-keys? (binding @dots{}) expr @dots{}
162 These macros pick out keyword arguments from @var{rest-arg}, but do not
163 modify it. This is consistent at least with Common Lisp, which
164 duplicates keyword arguments in the rest argument. More explanation of what
165 keyword arguments in a lambda list look like can be found below in
166 the documentation for @code{lambda*}
167 (@pxref{lambda* Reference}). @var{binding}s can have the same form as
168 for @code{let-optional}. If @var{allow-other-keys?} is false, an error
169 will be thrown if anything that looks like a keyword argument but does
170 not match a known keyword parameter will result in an error.
172 After binding the variables, the expressions @var{expr} @dots{} are
177 @node lambda* Reference
178 @subsection lambda* Reference
180 @c FIXME::martin: Review me!
182 When using optional and keyword argument lists, using @code{lambda} for
183 creating procedures and using @code{let-optional} or @code{let-keywords}
184 is a bit lengthy. Therefore, @code{lambda*} is provided, which combines
185 the features of those macros into a single convenient syntax.
187 For quick reference, here is the syntax of the formal argument list for
188 @code{lambda*} (brackets are used to indicate grouping only):
191 ext-param-list ::= [identifier]* [#:optional [ext-var-decl]+]?
192 [#:key [ext-var-decl]+ [#:allow-other-keys]?]?
193 [[#:rest identifier]|[. identifier]]?
195 ext-var-decl ::= identifier | ( identifier expression )
198 The characters `*', `+' and `?' are not to be taken literally; they mean
199 respectively, zero or more occurrences, one or more occurrences, and one
202 @deffn {library syntax} lambda* formals body
203 @code{lambda*} creates a procedure that takes optional arguments. These
204 are specified by putting them inside brackets at the end of the
205 parameter list, but before any dotted rest argument. For example,
208 (lambda* (a b #:optional c d . e) '())
211 creates a procedure with fixed arguments @var{a} and @var{b}, optional
212 arguments @var{c} and @var{d}, and rest argument @var{e}. If the
213 optional arguments are omitted in a call, the variables for them are
214 unbound in the procedure. This can be checked with the @code{bound?}
215 macro (documented below).
217 @code{lambda*} can also take keyword arguments. For example, a procedure
221 (lambda* (#:key xyzzy larch) '())
224 can be called with any of the argument lists @code{(#:xyzzy 11)}
225 @code{(#:larch 13)} @code{(#:larch 42 #:xyzzy 19)} @code{()}. Whichever
226 arguments are given as keywords are bound to values.
228 Optional and keyword arguments can also be given default values
229 which they take on when they are not present in a call, by giving a
230 two-item list in place of an optional argument, for example in:
233 (lambda* (foo #:optional (bar 42) #:key (baz 73))
237 @var{foo} is a fixed argument, @var{bar} is an optional argument with
238 default value 42, and baz is a keyword argument with default value 73.
239 Default value expressions are not evaluated unless they are needed and
240 until the procedure is called.
242 @code{lambda*} also supports two more special parameter list keywords.
244 @code{lambda*}-defined procedures now throw an error by default if a
245 keyword other than one of those specified is found in the actual
246 passed arguments. However, specifying @code{#:allow-other-keys}
247 immediately after the keyword argument declarations restores the
248 previous behavior of ignoring unknown keywords. @code{lambda*} also now
249 guarantees that if the same keyword is passed more than once, the
250 last one passed is the one that takes effect. For example,
253 ((lambda* (#:key (heads 0) (tails 0)) (display (list heads tails)))
254 #:heads 37 #:tails 42 #:heads 99)
257 would result in (99 47) being displayed.
259 @code{#:rest} is also now provided as a synonym for the dotted syntax
260 rest argument. The argument lists @code{(a . b)} and @code{(a #:rest b)}
261 are equivalent in all respects to @code{lambda*}. This is provided for
262 more similarity to DSSSL, MIT-Scheme and Kawa among others, as well as
263 for refugees from other Lisp dialects.
266 @deffn {library syntax} bound? variable
267 Check if a variable is bound in the current environment.
269 The procedure @code{defined?} doesn't quite cut it as it stands, since
270 it only checks bindings in the top-level environment, not those in local
275 @node define* Reference
276 @subsection define* Reference
278 @c FIXME::martin: Review me!
280 Just like @code{define} has a shorthand notation for defining procedures
281 (@pxref{Lambda Alternatives}), @code{define*} is provided as an
282 abbreviation of the combination of @code{define} and @code{lambda*}.
284 @code{define*-public} is the @code{lambda*} version of
285 @code{define-public}; @code{defmacro*} and @code{defmacro*-public} exist
286 for defining macros with the improved argument list handling
287 possibilities. The @code{-public} versions not only define the
288 procedures/macros, but also export them from the current module.
290 @deffn {library syntax} define* formals body
291 @deffnx {library syntax} define*-public formals body
292 @code{define*} and @code{define*-public} support optional arguments with
293 a similar syntax to @code{lambda*}. They also support arbitrary-depth
294 currying, just like Guile's define. Some examples:
297 (define* (x y #:optional a (z 3) #:key w . u)
298 (display (list y z u)))
300 defines a procedure @code{x} with a fixed argument @var{y}, an optional
301 argument @var{a}, another optional argument @var{z} with default value 3,
302 a keyword argument @var{w}, and a rest argument @var{u}.
305 (define-public* ((foo #:optional bar) #:optional baz) '())
308 This illustrates currying. A procedure @code{foo} is defined, which,
309 when called with an optional argument @var{bar}, returns a procedure
310 that takes an optional argument @var{baz}.
312 Of course, @code{define*[-public]} also supports @code{#:rest} and
313 @code{#:allow-other-keys} in the same way as @code{lambda*}.
316 @deffn {library syntax} defmacro* name formals body
317 @deffnx {library syntax} defmacro*-public name formals body
318 These are just like @code{defmacro} and @code{defmacro-public} except that they
319 take @code{lambda*}-style extended parameter lists, where @code{#:optional},
320 @code{#:key}, @code{#:allow-other-keys} and @code{#:rest} are allowed with the usual
321 semantics. Here is an example of a macro with an optional argument:
324 (defmacro* transmorgify (a #:optional b)
330 @node Procedure Properties
331 @section Procedure Properties and Meta-information
333 @c FIXME::martin: Review me!
335 Procedures always have attached the environment in which they were
336 created and information about how to apply them to actual arguments. In
337 addition to that, properties and meta-information can be stored with
338 procedures. The procedures in this section can be used to test whether
339 a given procedure satisfies a condition; and to access and set a
340 procedure's property.
342 The first group of procedures are predicates to test whether a Scheme
343 object is a procedure, or a special procedure, respectively.
344 @code{procedure?} is the most general predicates, it returns @code{#t}
345 for any kind of procedure. @code{closure?} does not return @code{#t}
346 for primitive procedures, and @code{thunk?} only returns @code{#t} for
347 procedures which do not accept any arguments.
350 @deffn {Scheme Procedure} procedure? obj
351 @deffnx {C Function} scm_procedure_p (obj)
352 Return @code{#t} if @var{obj} is a procedure.
355 @deffn {Scheme Procedure} closure? obj
356 @deffnx {C Function} scm_closure_p (obj)
357 Return @code{#t} if @var{obj} is a closure.
360 @deffn {Scheme Procedure} thunk? obj
361 @deffnx {C Function} scm_thunk_p (obj)
362 Return @code{#t} if @var{obj} is a thunk.
365 @c FIXME::martin: Is that true?
366 @cindex procedure properties
367 Procedure properties are general properties to be attached to
368 procedures. These can be the name of a procedure or other relevant
369 information, such as debug hints.
371 @deffn {Scheme Procedure} procedure-properties proc
372 @deffnx {C Function} scm_procedure_properties (proc)
373 Return @var{obj}'s property list.
376 @deffn {Scheme Procedure} procedure-property obj key
377 @deffnx {C Function} scm_procedure_property (obj, key)
378 Return the property of @var{obj} with name @var{key}.
381 @deffn {Scheme Procedure} set-procedure-properties! proc alist
382 @deffnx {C Function} scm_set_procedure_properties_x (proc, alist)
383 Set @var{obj}'s property list to @var{alist}.
386 @deffn {Scheme Procedure} set-procedure-property! obj key value
387 @deffnx {C Function} scm_set_procedure_property_x (obj, key, value)
388 In @var{obj}'s property list, set the property named @var{key} to
392 @cindex procedure documentation
393 Documentation for a procedure can be accessed with the procedure
394 @code{procedure-documentation}.
396 @deffn {Scheme Procedure} procedure-documentation proc
397 @deffnx {C Function} scm_procedure_documentation (proc)
398 Return the documentation string associated with @code{proc}. By
399 convention, if a procedure contains more than one expression and the
400 first expression is a string constant, that string is assumed to contain
401 documentation for that procedure.
404 @cindex source properties
405 @c FIXME::martin: Is the following true?
406 Source properties are properties which are related to the source code of
407 a procedure, such as the line and column numbers, the file name etc.
409 @deffn {Scheme Procedure} set-source-properties! obj plist
410 @deffnx {C Function} scm_set_source_properties_x (obj, plist)
411 Install the association list @var{plist} as the source property
415 @deffn {Scheme Procedure} set-source-property! obj key datum
416 @deffnx {C Function} scm_set_source_property_x (obj, key, datum)
417 Set the source property of object @var{obj}, which is specified by
418 @var{key} to @var{datum}. Normally, the key will be a symbol.
421 @deffn {Scheme Procedure} source-properties obj
422 @deffnx {C Function} scm_source_properties (obj)
423 Return the source property association list of @var{obj}.
427 @deffn {Scheme Procedure} source-property obj key
428 @deffnx {C Function} scm_source_property (obj, key)
429 Return the source property specified by @var{key} from
430 @var{obj}'s source property list.
434 @node Procedures with Setters
435 @section Procedures with Setters
437 @c FIXME::martin: Review me!
439 @c FIXME::martin: Document `operator struct'.
441 @cindex procedure with setter
443 A @dfn{procedure with setter} is a special kind of procedure which
444 normally behaves like any accessor procedure, that is a procedure which
445 accesses a data structure. The difference is that this kind of
446 procedure has a so-called @dfn{setter} attached, which is a procedure
447 for storing something into a data structure.
449 Procedures with setters are treated specially when the procedure appears
450 in the special form @code{set!} (REFFIXME). How it works is best shown
453 Suppose we have a procedure called @code{foo-ref}, which accepts two
454 arguments, a value of type @code{foo} and an integer. The procedure
455 returns the value stored at the given index in the @code{foo} object.
456 Let @code{f} be a variable containing such a @code{foo} data
457 structure.@footnote{Working definitions would be:
459 (define foo-ref vector-ref)
460 (define foo-set! vector-set!)
461 (define f (make-vector 2 #f))
466 (foo-ref f 0) @result{} bar
467 (foo-ref f 1) @result{} braz
470 Also suppose that a corresponding setter procedure called
471 @code{foo-set!} does exist.
475 (foo-ref f 0) @result{} bla
478 Now we could create a new procedure called @code{foo}, which is a
479 procedure with setter, by calling @code{make-procedure-with-setter} with
480 the accessor and setter procedures @code{foo-ref} and @code{foo-set!}.
481 Let us call this new procedure @code{foo}.
484 (define foo (make-procedure-with-setter foo-ref foo-set!))
487 @code{foo} can from now an be used to either read from the data
488 structure stored in @code{f}, or to write into the structure.
491 (set! (foo f 0) 'dum)
492 (foo f 0) @result{} dum
495 @deffn {Scheme Procedure} make-procedure-with-setter procedure setter
496 @deffnx {C Function} scm_make_procedure_with_setter (procedure, setter)
497 Create a new procedure which behaves like @var{procedure}, but
498 with the associated setter @var{setter}.
501 @deffn {Scheme Procedure} procedure-with-setter? obj
502 @deffnx {C Function} scm_procedure_with_setter_p (obj)
503 Return @code{#t} if @var{obj} is a procedure with an
504 associated setter procedure.
507 @deffn {Scheme Procedure} procedure proc
508 @deffnx {C Function} scm_procedure (proc)
509 Return the procedure of @var{proc}, which must be either a
510 procedure with setter, or an operator struct.
513 @deffn {Scheme Procedure} setter proc
514 Return the setter of @var{proc}, which must be either a procedure with
515 setter or an operator struct.
520 @section Lisp Style Macro Definitions
523 @cindex transformation
524 Macros are objects which cause the expression that they appear in to be
525 transformed in some way @emph{before} being evaluated. In expressions
526 that are intended for macro transformation, the identifier that names
527 the relevant macro must appear as the first element, like this:
530 (@var{macro-name} @var{macro-args} @dots{})
533 In Lisp-like languages, the traditional way to define macros is very
534 similar to procedure definitions. The key differences are that the
535 macro definition body should return a list that describes the
536 transformed expression, and that the definition is marked as a macro
537 definition (rather than a procedure definition) by the use of a
538 different definition keyword: in Lisp, @code{defmacro} rather than
539 @code{defun}, and in Scheme, @code{define-macro} rather than
543 @fnindex define-macro
544 Guile supports this style of macro definition using both @code{defmacro}
545 and @code{define-macro}. The only difference between them is how the
546 macro name and arguments are grouped together in the definition:
549 (defmacro @var{name} (@var{args} @dots{}) @var{body} @dots{})
556 (define-macro (@var{name} @var{args} @dots{}) @var{body} @dots{})
560 The difference is analogous to the corresponding difference between
561 Lisp's @code{defun} and Scheme's @code{define}.
563 @code{false-if-exception}, from the @file{boot-9.scm} file in the Guile
564 distribution, is a good example of macro definition using
568 (defmacro false-if-exception (expr)
575 The effect of this definition is that expressions beginning with the
576 identifier @code{false-if-exception} are automatically transformed into
577 a @code{catch} expression following the macro definition specification.
581 (false-if-exception (open-input-file "may-not-exist"))
584 (lambda () (open-input-file "may-not-exist"))
590 @section The R5RS @code{syntax-rules} System
591 @cindex R5RS syntax-rules system
593 R5RS defines an alternative system for macro and syntax transformations
594 using the keywords @code{define-syntax}, @code{let-syntax},
595 @code{letrec-syntax} and @code{syntax-rules}.
597 The main difference between the R5RS system and the traditional macros
598 of the previous section is how the transformation is specified. In
599 R5RS, rather than permitting a macro definition to return an arbitrary
600 expression, the transformation is specified in a pattern language that
604 does not require complicated quoting and extraction of components of the
605 source expression using @code{caddr} etc.
608 is designed such that the bindings associated with identifiers in the
609 transformed expression are well defined, and such that it is impossible
610 for the transformed expression to construct new identifiers.
614 The last point is commonly referred to as being @dfn{hygienic}: the R5RS
615 @code{syntax-case} system provides @dfn{hygienic macros}.
617 For example, the R5RS pattern language for the @code{false-if-exception}
618 example of the previous section looks like this:
628 In Guile, the @code{syntax-rules} system is provided by the @code{(ice-9
629 syncase)} module. To make these facilities available in your code,
630 include the expression @code{(use-modules (ice-9 syncase))} or
631 @code{(use-syntax (ice-9 syncase))} (@pxref{Using Guile Modules})
632 before the first usage of @code{define-syntax} etc. If you are writing
633 a Scheme module, you can alternatively use one of the keywords
634 @code{#:use-module} and @code{#:use-syntax} in your @code{define-module}
635 declaration (@pxref{Creating Guile Modules}).
638 * Pattern Language:: The @code{syntax-rules} pattern language.
639 * Define-Syntax:: Top level syntax definitions.
640 * Let-Syntax:: Local syntax definitions.
644 @node Pattern Language
645 @subsection The @code{syntax-rules} Pattern Language
649 @subsection Top Level Syntax Definitions
651 define-syntax: The gist is
653 (define-syntax <keyword> <transformer-spec>)
655 makes the <keyword> into a macro so that
659 expands at _compile_ or _read_ time (i.e. before any
660 evaluation begins) into some expression that is
661 given by the <transformer-spec>.
665 @subsection Local Syntax Definitions
669 @section Support for the @code{syntax-case} System
673 @node Internal Macros
674 @section Internal Representation of Macros and Syntax
676 Internally, Guile uses three different flavors of macros. The three
677 flavors are called @dfn{acro} (or @dfn{syntax}), @dfn{macro} and
687 with @code{foo} being some flavor of macro, one of the following things
688 will happen when the expression is evaluated.
692 When @code{foo} has been defined to be an @dfn{acro}, the procedure used
693 in the acro definition of @code{foo} is passed the whole expression and
694 the current lexical environment, and whatever that procedure returns is
695 the value of evaluating the expression. You can think of this a
696 procedure that receives its argument as an unevaluated expression.
699 When @code{foo} has been defined to be a @dfn{macro}, the procedure used
700 in the macro definition of @code{foo} is passed the whole expression and
701 the current lexical environment, and whatever that procedure returns is
702 evaluated again. That is, the procedure should return a valid Scheme
706 When @code{foo} has been defined to be a @dfn{mmacro}, the procedure
707 used in the mmacro definition of `foo' is passed the whole expression
708 and the current lexical environment, and whatever that procedure returns
709 replaces the original expression. Evaluation then starts over from the
710 new expression that has just been returned.
713 The key difference between a @dfn{macro} and a @dfn{mmacro} is that the
714 expression returned by a @dfn{mmacro} procedure is remembered (or
715 @dfn{memoized}) so that the expansion does not need to be done again
716 next time the containing code is evaluated.
718 The primitives @code{procedure->syntax}, @code{procedure->macro} and
719 @code{procedure->memoizing-macro} are used to construct acros, macros
720 and mmacros respectively. However, if you do not have a very special
721 reason to use one of these primitives, you should avoid them: they are
722 very specific to Guile's current implementation and therefore likely to
723 change. Use @code{defmacro}, @code{define-macro} (@pxref{Macros}) or
724 @code{define-syntax} (@pxref{Syntax Rules}) instead. (In low level
725 terms, @code{defmacro}, @code{define-macro} and @code{define-syntax} are
726 all implemented as mmacros.)
728 @deffn {Scheme Procedure} procedure->syntax code
729 @deffnx {C Function} scm_makacro (code)
730 Return a @dfn{macro} which, when a symbol defined to this value
731 appears as the first symbol in an expression, returns the
732 result of applying @var{code} to the expression and the
736 @deffn {Scheme Procedure} procedure->macro code
737 @deffnx {C Function} scm_makmacro (code)
738 Return a @dfn{macro} which, when a symbol defined to this value
739 appears as the first symbol in an expression, evaluates the
740 result of applying @var{code} to the expression and the
741 environment. The value returned from @var{code} which has been
742 passed to @code{procedure->memoizing-macro} replaces the form
743 passed to @var{code}. For example:
748 (lambda (x env) `(set! ,(cadr x) (tracef ,(cadr x) ',(cadr x))))))
750 (trace @i{foo}) @equiv{} (set! @i{foo} (tracef @i{foo} '@i{foo})).
754 @deffn {Scheme Procedure} procedure->memoizing-macro code
755 @deffnx {C Function} scm_makmmacro (code)
756 Return a macro which, when a symbol defined to this value appears as the
757 first symbol in an expression, evaluates the result of applying
758 @var{code} to the expression and the environment.
759 @code{procedure->memoizing-macro} is the same as
760 @code{procedure->macro}, except that the expression returned by
761 @var{code} replaces the original macro expression in the memoized form
762 of the containing code.
765 In the following primitives, @dfn{acro} flavor macros are referred to
766 as @dfn{syntax transformers}.
768 @deffn {Scheme Procedure} macro? obj
769 @deffnx {C Function} scm_macro_p (obj)
770 Return @code{#t} if @var{obj} is a regular macro, a memoizing macro or a
774 @deffn {Scheme Procedure} macro-type m
775 @deffnx {C Function} scm_macro_type (m)
776 Return one of the symbols @code{syntax}, @code{macro} or
777 @code{macro!}, depending on whether @var{m} is a syntax
778 transformer, a regular macro, or a memoizing macro,
779 respectively. If @var{m} is not a macro, @code{#f} is
783 @deffn {Scheme Procedure} macro-name m
784 @deffnx {C Function} scm_macro_name (m)
785 Return the name of the macro @var{m}.
788 @deffn {Scheme Procedure} macro-transformer m
789 @deffnx {C Function} scm_macro_transformer (m)
790 Return the transformer of the macro @var{m}.
793 @deffn {Scheme Procedure} cons-source xorig x y
794 @deffnx {C Function} scm_cons_source (xorig, x, y)
795 Create and return a new pair whose car and cdr are @var{x} and @var{y}.
796 Any source properties associated with @var{xorig} are also associated
802 @c TeX-master: "guile.texi"