Python has the keyword.iskeyword method we can leverage for Python
keywords, but we also need to address Hy builtins like 'get' or
'slice'.
And to make behavior compatible with Python 2 or 3, we also make
a special case to prevent assignment to False, True or None as
well as the Hy versions: false, true, null, and nil.
For non-Hy modules, we also check to make sure the symbol is not
part of the compiler. This allows shadow.hy to override "+" but
prevents general use from re-defn-ing 'get' or 'do'.
As noted in #600, Python 3 allows a return inside a generator
method, that raises a StopIteration and passes the return value
inside the 'value' attr of the exception.
To allow this behaviour we simple set 'contains_yield' while compiling
'yield', thus allowing a return statement, but only for Python 3. Then
when compiling the try-except, we check for contains_yield to decide
whether there will be a return.
This allows code like:
(defn gen []
(yield 3)
"goodbye")
to compile in both Py2 and Py3. The return value is simply ignored in
Python 2.
hy2py in Python 2 gives:
def g():
yield 3L
u'goodbye'
while hy2py in Python 3 gives:
def g():
yield 3
return 'goodbye'
Turns out return in yield started in Python 3.3
This new core module allows us to shadow the builtin Python operators so
they may be passed to sequence functions that expect functions:
=> (map / [1 2 3 4 5])
[1.0, 0.5, 0.3333333333333333, 0.25]
Currently, defmacro/g! doesn't respond well when it comes across a
HyObject that doesn't respond to the instance method startswith (e.g.
HyInteger, HyFloat, etc.). This updates defmacro/g! to be a little
safer when searching for the gensyms it needs to create.
This also breaks out the PY3 only tests into their own file. We need to do this because raise from is a syntax error in PY2, so we can't rely on the previous hack of catching a HyCompileError - it would compile fine through Hy and then be a syntax error in Python.
As a result:
* functions such as `nth` should work correctly on iterators;
* `nth` will raise `IndexError` (in a fashion consistent with `get`)
when the index is out of bounds;
* `take`, etc. will raise `ValueError` instead of returning
an ambiguous value if the index is negative;
* `map`, `zip`, `range`, `input`, `filter` work the same way (Py3k one)
on both Python 2 and 3 (see #523 and #331).
Also small DRYing in try handling.
Previously, writing a bare (try (foo)) would invoke Pokemon
exception catching (gotta catch 'em all) instead of the correct
behavior, which is to raise the exception if no handler is provided.
Note that this is a cute feature of Hy, as a `try` with no `except`
is a syntax error. We avoid the syntax error here because we don't
use Python's compiler, which is the only thing that can throw
Syntax Errors. :D
Fixes#555.
The yield-from that existed previously wasn't actually implementing the
full complexity of "yield from":
http://legacy.python.org/dev/peps/pep-0380/#formal-semantics
... this includes passing along errors, and many other things.
Also removes the yield-from backport macro, since it does not seem
possible at present to conditionally build macros.
Thus, there is no longer yield-from on pre-python-3.3 systems.
Includes updated docs and tests to reflect all this.
Example:
(defmain [&rest args]
(print "now we're having a fun time!")
(print args))
Which outputs:
$ hy test.hy
now we're having a fun time!
(['test.hy'],)
Includes documentation and tests.
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.
When (import) encounters anything but a HySymbol or HyList, raise an
exception, as that is not valid in Hy. Previously, anything other than a
HySymbol or HyList was simply ignored, turning that particular import
into a no-op, which was both wrong and confusing.
Reported-by: Richard Parsons <richard.lee.parsons@gmail.com>
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This function will recursively perform all possible macroexpansions in
the supplied form. Unfortunately, it also traverses into quasiquoted
parts, where it shouldn't, but it is a useful estimation of macro
expansion anyway.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The hy.contrib.walk module provides a few functions to walk the Hy AST,
and potentially transform it along the way. The main entry point
is (walk), which takes two functions and a form as arguments, and
applies the first (inner) function to each element of the form, building
up a data structure of the same type as the original. Then applies outer
(the second function) to the result.
Two convenience functions are provided: (postwalk) and (prewalk), which
do a depth-first, post/pre-order traversal of the form.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* hy/core/language.hy: Adding a simple `identity` function that returns
the argument supplied to it
* docs/language/core.rst: Updated docs with identity function
Sometimes it is better to start with the false condition, sometimes that
makes the code clearer. For that, the (if-not) macro, which simply
reverses the order of the condition blocks, can be of great use.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
In the same vein as defmacro-alias, this implements defn-alias /
defun-alias, which does essentially the same thing as defmacro-alias,
but for functions.
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
With this patch, every identifier is split up along dots, each part gets
separately mangled, and then it is all joined back together. This allows
for fun stuff like (.foo? (Foo)), and even more contrived examples.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The hy2py tool has been very useful for me, but most of the time, it's
only a part of its output that one is interested in. The whole output,
with source code, AST and python code together is one big monstrosity.
So instead of printing all that, lets have a few handy command-line
options to control which part gets printed.
By default, only the generated python source is, as that's what the name
of the tool implies.
Also, don't run it. That's what hy is for.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There's no reason why one would need to choose between --spy and -i, so
pass down options.spy to run_icommand, and then to HyREPL, so we can
have both.
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
* hy/core/language.hy:
-Added a simple coll? function that checks whether the given argument
is an iterable and not a string,
- Also replaced the check in `flatten` by coll?
* tests/native_tests/core.hy: Tests updated for checking coll?
This cleans up a number of doc warnings, including a bad
underline for zero?
While there, added a nil? function to match up with the
new nil is None.
Also un-hid myself from coreteam.
This version is much simpler.
At the point that the exception is raised, we don't have access to
the actual source, just the current expression. but as the
exception percolates up, we can intercept it, add the source and
the re-raise it.
Then at the final point, in the cmdline handler, we can choose to
let the entire traceback print, or just the simpler, direct error
message.
And even with the full traceback, the last bit is nicely formatted
just like the shorter, simpler message.
The error message is colored if clint is installed, but to avoid
yet another dependency, you get monochrome without clint.
I'm sure there is a better way to do the markup, the current method
is kludgy but works.
I wish there was more shared code between HyTypeError and LexException
but they are kind of different in some fundamental ways.
This doesn't work (yet) with runtime errors generated from Python,
like NameError, but I have a method that can catch NameError and turn it
into a more pleasing output.
Finally, there is no obvious way to raise HyTypeError from pure Hy code,
so methods in core/language.hy throw ugly TypeError/ValueError.
