GNU bug report logs -
#42456
[PATCH] gnu: Rename python-hy to hy.
Previous Next
Full log
Message #20 received at 42456 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 348 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.