You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/macros.rst
+12-5Lines changed: 12 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -70,7 +70,7 @@ You don't need to always return a model because the compiler calls :hy:func:`hy.
70
70
Arguments are always passed in as models. You can use quasiquotation (see :hy:func:`quasiquote`) to concisely define a model with partly literal and partly evaluated components::
71
71
72
72
(defmacro set-to-2 [variable]
73
-
`(setv ~variable 2))
73
+
`(setv ~variable 2))
74
74
(set-to-2 foobar)
75
75
(print foobar)
76
76
@@ -160,19 +160,26 @@ By the way, despite the need for ``eval-and-compile``, extracting a lot of compl
160
160
The important take-home big fat WARNING
161
161
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
162
162
163
-
A typical macro should use only four kinds of names in its expansion: gensyms, core macros, objects that Python puts in scope by default (like its built-in functions), and ``hy`` and its attributes. It's possible to rebind nearly all these names, so surprise shadowing is still theoretically possible. Unfortunately, the only way to prevent these pathological rebindings from coming about is… don't do that. Don't make a new macro named ``setv`` or name a function argument ``type`` unless you're ready for every macro you call to break, the same way you wouldn't monkey-patch a built-in Python module without thinking carefully. This kind of thing is the responsibility of the macro caller; the macro writer can't do much to defend against it. There is at least a pragma :ref:`warn-on-core-shadow <warn-on-core-shadow>`, enabled by default, that causes ``defmacro`` and ``require`` to warn you if you give your new macro the same name as a core macro.
163
+
A typical macro should use only names of these four kinds in its expansion:
164
+
165
+
- gensyms
166
+
- core macros
167
+
- objects that Python puts in scope by default (like its built-in functions)
168
+
- ``hy`` and its attributes
169
+
170
+
It's possible to rebind nearly all these names, so surprise shadowing is still theoretically possible. Unfortunately, the only way to prevent these pathological rebindings from coming about is… don't do that. Don't make a new macro named ``setv`` or name a function parameter ``type`` unless you're ready for every macro you call to break, the same way you wouldn't monkey-patch a built-in Python module without thinking carefully. This kind of thing is the responsibility of the macro caller; the macro writer can't do much to defend against it. There is at least a pragma :ref:`warn-on-core-shadow <warn-on-core-shadow>`, enabled by default, that causes ``defmacro`` and ``require`` to warn you if you give your new macro the same name as a core macro.
164
171
165
172
.. _reader-macros:
166
173
167
174
Reader macros
168
175
-------------
169
176
170
-
Reader macros allow you to hook directly into Hy's parser to customize how text is parsed into models. They're defined with :hy:func:`defreader <hy.core.macros.defreader>`, or, like regular macros, brought in from other modules with :hy:func:`require`. Rather than receiving function arguments, a reader macro has access to a :py:class:`hy.HyReader` object named ``&reader``, which provides all the text-parsing logic that Hy uses to parse itself (see :py:class:`hy.HyReader` and its base class :py:class:`hy.Reader` for the available methods). A reader macro is called with the hash sign ``#``, and like a regular macro, it should return a model or something convertible to a model.
177
+
Reader macros allow you to hook into Hy's parser to customize how text is parsed into models. They're defined with :hy:func:`defreader <hy.core.macros.defreader>`, or, like regular macros, brought in from other modules with :hy:func:`require`. Rather than receiving function arguments, a reader macro has access to a :py:class:`hy.HyReader` object named ``&reader``, which provides all the text-parsing logic that Hy uses to parse itself (see :py:class:`hy.HyReader` and its base class :py:class:`hy.Reader` for the available methods). A reader macro is called with the hash sign ``#``, and like a regular macro, it should return a model or something convertible to a model.
171
178
172
179
The simplest kind of reader macro doesn't read anything::
173
180
174
181
(defreader hi
175
-
`(print "Hello."))
182
+
'(print "Hello."))
176
183
177
184
#hi #hi #hi
178
185
@@ -233,7 +240,7 @@ There are three scoped varieties of regular macro. First are **core macros**, wh
Copy file name to clipboardExpand all lines: hy/core/macros.hy
+2-4Lines changed: 2 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,5 @@
1
-
;;; Hy core macros
1
+
"This file has the few core macros that are implemented in Hy instead of Python."
2
2
3
-
;;; These macros form the hy language
4
-
;;; They are automatically required in every module, except inside hy.core
5
3
6
4
(defmacrocond [#* args]
7
5
"Shorthand for a nested sequence of :hy:func:`if` forms, like an
@@ -121,7 +119,7 @@
121
119
(help (get (local-macros) "m")))
122
120
(f)
123
121
124
-
The equivalency is rough in the sense that ``local-macros`` returns a literal dictionary, not a preexisting object that Hy uses for resolving macro names. So, modifying the dictionary will have no effect.
122
+
The equivalency is rough in the sense that ``local-macros`` expands to a literal dictionary, not a preexisting object that Hy uses for resolving macro names. So, modifying the dictionary will have no effect.
125
123
126
124
See also :hy:func:`get-macro <hy.core.macros.get-macro>`.]]
0 commit comments