* Add comp, constantly and complement
relates #1176
* Fix composition order in comp
* comp without parameters returns identity
* Doc edits for comp, complement, constantly
* Test that `(comp)` returns `identity` exactly
* Simplify the `reduce` call in `comp`
* updated version of comp
* 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
Per the straw poll in #908, as an alternative to #1147.
Now you must use `True`, `False`, and `None`, as in Python. Or just assign `true` to `True`, etc.; the old synonyms aren't reserved words anymore.
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 them to be used with numeric types that aren't built in, such as NumPy arrays. Because Python uses duck typing, there's generally no way to know in advance whether a given value will accept a given operator. Of course, things like `(inc "hello")` will still raise a `TypeError`, because so does `(+ "hello" 1)`.
