Unlike Python, Hy allows the programmer to intermingle positional and keyword arguments. This change removes an exception to that rule for method calls, in which the method callee always had to be the first thing after the method. Thus, `(.split :sep "o" "foo")` now compiles to `"foo".split(sep="o")` instead of `HyKeyword("sep").split("o", "foo")`.
I don't see why you'd put this in the standard library. I guess it could be useful for when you're maintaining a library and you want to change the name of a function or macro but keep the old name around for a while so people's code doesn't break immediately. But that's a pretty limited purpose.
* 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
I have some macros for using pandas and NumPy that expect : to be a keyword instead of an ordinary symbol. These tests will ensure that we don't break this unless we want to.
* 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.
In Python 2.x (range 10) is mapped to xrange(10) in Python
terms. However, xrange doesn't support slicing, which caused tests to
fail. By forxing xrange into list, we have slicing available.
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)`.
This makes it possible to use strings as the macro name argument to
defreader, which in turn makes it possible to define reader macros with
names that would otherwise result in parse errors.
Such as `#.`.
This fixes#918.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The `if` form now supports elif clauses.
It works like `cond` but without the implicit `do`.
The old `if` is now `if*`
variadic lif now supports "ellif" clauses.
Update if-no-waste compiler to use `if*` properly.
(Sometimes one character is all it takes.)
document if
reword truthiness
Comparison operators such as =, !=, <, >, <=, >= should support a
one-arity version too, and return true in those cases (except for !=,
which returns false).
This closes#949.
Reported-by: Matthew Egan Odendahl
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This changes with syntax from (with [[x (expr)] (expr)] ...) to (with
[x (expr) (expr)] ...). Should have no ill side effects apart from the
syntax change.
Closes#852.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This changes let to use a flat list of symbol-value pairs instead of a
vector of vectors. One side effect is that (let [[a 1] z]) is not
expressible now, and one will explicitly need to set a nil value for z,
such as: (let [a 1 z nil]).
Closes#713.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
apply now mangles strings and keywords according to the Hy mangling
rules (by using the same function, now imported from
hy.lex.parser). With this change, if the dict passed to apply has
keywords, strings or quoted symbols, they'll get mangled, to turn them
into proper keys.
This only works for the cases where the keys are directly in the apply
params. A previously deffed dict, or key through a variable will not be
mangled.
This closes#219.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make it easier to write --init-- functions, defclass will now check
any (setv) expressions (and its property list), to find any --init--
declarations, and append a nil to the end.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
For easier macro writing purposes, allow an empty (cond), that simply
returns nil. Closes#904.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To mirror the behaviour of (setv), allow an empty (del) too: one that
shall return nil. Closes#905.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
defclass now has a new syntax:
(defclass Name [BaseList]
[property value
property value] ;; optional
(defn method [self]
self.property))
Anything after the optional property list (which will be translated to a
setv within the class context) will be added to the class body. This
allows one to have side effects and complex expressions within the class
definition.
As a side effect, defining methods is much more friendly now!
Closes#850.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
xor with more than two input parameters is not well defined and people
have different expectations on how it should behave. Avoid confusion by
sticking with two parameters only.
Added xor to complement and, or, not operators. Standard python
falsey/truthy semantics are followed. This implementation works for
two or more parameters.