This commit adds just enough namespacing to resolve a macro first in the macro's
defining module's namespace (i.e. the module assigned to the `HyASTCompiler`),
then in the namespace/module it's evaluated in. Namespacing is accomplished by
adding a `module` attribute to `HySymbol`, so that `HyExpression`s can be
checked for this definition namespace attribute and their car symbol resolved
per the above.
As well, a couple tests have been added that cover
- the loading of module-level macros
- e.g. that only macros defined in the `require`d module are added
- the AST generated for `require`
- using macros loaded from modules imported via bytecode
- the non-local macro namespace resolution described above
- a `require`d macro that uses a macro `require` exclusively in its
module-level namespace
- and that (second-degree `require`d) macros can reference variables within
their module-level namespaces.
Closeshylang/hy#1268, closeshylang/hy#1650, closeshylang/hy#1416.
Python 3.x is patched in a way that integrates `.hy` source files into
Pythons default `importlib` machinery. In Python 2.7, a PEP-302 "importer"
and "loader" is implemented according to the standard `import` logic (via
`pkgutil` and later pure-Python `imp` package code).
In both cases, the entry-point for the loaders is through `sys.path_hooks` only.
As well, the import semantics have been updated all throughout to utilize
`importlib` and follow aspects of PEP-420. This, along with some light
patches, should allow for basic use of `runpy`, `py_compile` and `reload`.
In all cases, if a `.hy` file is shadowed by a `.py`, Hy will silently use
`.hy`.
Auto-promotion now occurs in only two cases: when we start the compiler and when we expand a macro. It's fully recursive so even a non-model nested in a model will be promoted.
This change fixes some regressions induced by the stricter type checks of the pattern-matching compiler.
This copying is what keeps all the mutating code in the compiler methods (e.g., `expr.pop(0)`) from breaking cases in which Hy model objects are compiled more than once or inspected after compilation.
* added defmacro!
* revert #924#924 had an error and should never have been merged in the first place. (see #903)
* put back import getargspec
Without the `formatargspec` this time.
* Give better error message on failed macro expansion
Better error messages work most of the time. In cases where there are
parameters that aren't valid in Python, error message shown is rather
ugly. But this is better than no error messages at all and such
macros with strange parameter names are rather rare.
* fix flake8 errors
* Minor English improvements
Give `require` the same features as `import`
You can now do (require foo), (require [foo [a b c]]), (require [foo [*]]), and (require [foo :as bar]). The first and last forms get you macros named foo.a, foo.b, etc. or bar.a, bar.b, etc., respectively. The second form only gets the macros in the list.
Implements #1118 and perhaps partly addresses #277.
N.B. The new meaning of (require foo) will cause all existing code that uses macros to break. Simply replace these forms with (require [foo [*]]) to get your code working again.
There's a bit of a hack involved in the forms (require foo) or (require [foo :as bar]). When you call (foo.a ...) or (bar.a ...), Hy doesn't actually look inside modules. Instead, these (require ...) forms give the macros names that have periods in them, which happens to work fine with the way Hy finds and interprets macro calls.
* Make `require` syntax stricter and add tests
* Update documentation for `require`
* Documentation wording improvements
* Allow :as in `require` name lists
This allows macros to take a keyword dict containing useful things by
defining a keyword argument. This allows us to pass in new objects
which might be handy to have in macros.
This changeset refactors module_name to become `compiler`, so that we
can pass the compiler itself into the macros as `opts['compiler']`.
This allows the macro to both get the macro name
(`compiler.module_name`), as well as use the compiler to build AST.
In the future, this will enable us to create "super-macros" which return
AST, not HyAST, in order to manually create insane things from userland.
For userland macros (not `defmacro`) the core.language `macroexpand`
will go ahead and make a new compiler for you.
The `with-decorator` special form is not the most ergonomic—this commit
introduces a new builtin `#@` reader macro that expands to an invocation
of `with-decorator`. To support this, `reader_macroexpand` is made to
also look in the default `None` namespace, in imitation of how
regular (non-reader) macros defined in hy.core are looked up. The
docstring of `hy.macros.reader` is also edited slightly for accuracy.
This in the matter of issue #856.
Currently '.replace' method is used to replace hy objects. This is not
safe when we are not sure if the 'obj' in 'obj.replace(other)' is an
instance of HyObject.
In these cases, we can use function 'replace_hy_obj(obj, other)'
instead. This function will try to wrap 'obj' if it's not an instance of
HyObject.
This also means that we need a wrapping function in hy.models'. Hence I
moved the '_wrap_value' function from hy.macros into hy.models. To avoid
circular importing, the wrapper functions are provided individually by
each model type's own file.
For example:
```
$ hy
hy 0.10.1 using CPython(default) 2.7.8 on Darwin
=> (defmacro hi [] (raise (TypeError "This message will be truncated")))
=> (hi)
File "<input>", line 1, column 1
(hi)
^--^
HyMacroExpansionError: `hi' message will be truncated
````
One would expect the form:
> (defmacro a (&rest b) b)
> (a 1 2)
To return a tuple object but we have no Hy model so it returns a HyList.
Not sure if this is the right thing to do.
Added first iteration of reader macros
Refactored defmacro and defreader
Added test inn hy/tests/lex/test_lex.py
Added new test in hy/tests/native/tests
Added new test in hy/tests/macros.
changed the error given in the dispatch macro and added some handling for missing symbol and invalid characters
There was a couple of duplicate imports and type checkings in the
codebase. So I added a new module to unify all Python 2 and 3
compatibility codes.
Also, this is a somewhat common pattern in Python. See Jinja2 for
example:
https://github.com/mitsuhiko/jinja2/blob/master/jinja2/_compat.py
This will let us use (basic) yield from behavior from Python 2. This
isn't complete, and is low-hanging fruit for others willing to hack
on hy.
I've also changed the macrosystem to allow for proper bootstrapping.
This is similar to how it's done elsewhere in the codebase (stdlib
stuff).
Brandon T. Willard