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

[Jesse Gibbons]

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 
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?

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.

> 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
> representation.
>
> 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
> gnu/packages/guile-xyz.scm
>
>
> Cheers,
> simon

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.