Dear,
On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons <jgibbons2357@gmail.com> wrote:
What about Hy macros? According to
https://docs.hylang.org/en/stable/language/api.html#require they make no
changes to the program when imported with require. If I write a Hy
library with nothing but useful macros, will python be able to use that?
Macros will be represented as HyExpression or something like that (I
have not checked now and I have not played with Hy since 2014 :-)). Say
an HyObject which then needs to be “compiled” into a Python AST, then
the Python AST is “compiled” to bytecode.
https://docs.hylang.org/en/master/language/internals.html
Or simply said:
What if you want to use a macro that’s defined in a different
module? import won’t help, because it merely translates to a
Python import statement that’s executed at run-time, and macros
are expanded at compile-time, that is, during the translation
from Hy to Python. Instead, use require, which imports the
module and makes macros available at compile-time. require uses
the same syntax as import.
https://docs.hylang.org/en/master/tutorial.html#macros
--8<---------------cut here---------------start------------->8---
$ hy --spy
=> (defmacro do-while [condition &rest body]
`(do
~body
(while ~condition
~body)))
from hy import HyExpression, HySymbol
import hy
hy.macros.macro('do-while')(lambda hyx_XampersandXname, condition, *body:
HyExpression([] + [HySymbol('do')] + [body] + [HyExpression([] + [
HySymbol('while')] + [condition] + [body])]))
<function do_while at 0x7f846ec80430>
--8<---------------cut here---------------end--------------->8---
Does it make sense?
When I call Hy2py on a Hy file with nothing but the sample macro at
https://docs.hylang.org/en/stable/language/api.html#defmacro it gives an
error. Is this expected, or is this a guix-related bug? If this is
expected, then I think Hy macros are significantly more useful to Hy
than to python without the ast library, and if you want to use Hy macros
for parts of a python app you might as well use Hy.
Python and Hy are not one-to-one.
Hy also removes Python’s restrictions on mixing expressions and
statements, allowing for more direct and functional code. […]
https://docs.hylang.org/en/master/whyhy.html
So your problem hy2py seems expected. The macro is represented by a Hy
AST which cannot be compiled to Python AST.
However, note that “hy2py” is not bullet-proof because going from AST to
Python code is not straightforward.
--8<---------------cut here---------------start------------->8---
$ echo "(defn f [n] (+ n 1))" | hy2py --with-ast -
Module(
body=[
FunctionDef(name='f',
args=arguments(posonlyargs=[],
args=[arg(arg='n', annotation=None)],
vararg=None,
kwonlyargs=[],
kw_defaults=[],
kwarg=None,
defaults=[]),
body=[Return(value=BinOp(left=Name(id='n'), op=Add,
right=Constant(value=1)))],
decorator_list=[],
returns=None)
Traceback (most recent call last):
File
"/gnu/store/b2cyhq822sywidaqnpg6kminvr34z9rq-python-hy-0.18.0/bin/.hy2py-real", line
12, in <module>
sys.exit(hy2py_main())
[...]
File
"/gnu/store/i7bq751zql0vw1mb3x20k7fla9ilszwh-python-astor-0.7.1/lib/python3.8/site-packages/astor/op_util.py",
line 102, in get_op_precedence
return precedence_data[type(obj)]
KeyError: <class '_ast.Constant'>
--8<---------------cut here---------------end--------------->8---
Well, it could also be a bug… :-)
I do not think it makes sense having 'hy-build-system' because Hy uses
all the Python machinery, not to say Hy is simply Python with
parenthensis. ;-)
As I mentioned, hy-build-system would just make things a little more
convenient. Programs written even partially in Hy will require the Hy
package, but I wouldn't bother hacking a new build system together
unless there are other things required for all Hy packages. Do such
things exist? If not, I will let it go.
>From my point of point, Hy packages are just Python packages. For
instance, the 2 Hy libraries you mentioned are regular PyPI package,
installable with “pip”. Well, python-hy would be an implicit dependency
but AFAIK that’s all.
Similar things can be said of Clojure. Clojure is compiled into Java
bytecode, then run on the Java VM. Java programs can run Clojure code,
and vice versa. And just like Clojure and Java, Hy and Python have very
different grammar and are therefore not the same language. Yet Clojure
is not packaged as java-clojure.
I do not know well Clojure neither the Java ecosystem. But I think the
distribution of Clojure packages is a bit different than the
distribution of some other Java packages. The tools used to build are
not necessary the sames. Which is not the case for Hy: it uses “pip”
and/or the Python setuptools – it could have changed since I am not
following Hy very closely.
Though inconsistencies in naming conventions tend to bother me, I
personally am indifferent about what Hy is named. As the saying goes, "A
cactus by any other name would pop all the balloons you throw at it that
don't completely miss it." (Or something like that.) I only submitted
the patch because I had renamed python-hy to hy in my personal channel a
while ago, and the people on the IRC suggested I should send the change
as a patch when I mentioned it there recently. So if my patch is
accepted is up to those who are more familiar with Hy and Guix than I
am. I think the only time it will matter to me is if I am the first to
submit a package that requires Hy, since such a package will be written
for my channel and my channel won't be adjusted by then to build a
package dependent on hy.
About the name, I am indifferent too. :-)
Well, it could be nice to split the big Python files. ;-)
All the best,
simon
ps:
Note that I said “Hy code compiles to Python (and vice versa :-))” which
is inaccurate; especially about the “vice versa”. ;-)