[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#42456] [PATCH] gnu: Rename python-hy to hy.

From: Jesse Gibbons
Subject: [bug#42456] [PATCH] gnu: Rename python-hy to hy.
Date: Mon, 27 Jul 2020 17:05:43 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.10.0

It seems you understand a lot more about Hy than I do (I've never actually built a Hy app in my life, and I despise python (hence the interest in Hy)), so I have some questions. I'm trying to clear up some of my confusion.

On 7/27/20 8:40 AM, zimoun wrote:
Hy uses the Python VM.  Basically, the Hy Lisp is transformed into an
AST (from ast import *) i.e. Python internals then evaluated using the
Python VM (CPython or PyPy).
Other said, any Hy code compiles to Python (and vice versa :-)).

What about Hy macros? According to 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?

When I call Hy2py on a Hy file with nothing but the sample macro at 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.

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.
Other said, Python code can import Hy code, and vice versa, and not
because there is "bindings" but because it is the same AST

Last, I am not convinced that Hy deserves a rename since it is another
Python flavor.  Well, similarly than python-on-guile which is in


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.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]