[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 22:50:49 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.10.0

On 7/27/20 8:17 PM, zimoun wrote:

On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons <> wrote:

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

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.

--8<---------------cut here---------------start------------->8---
$ hy --spy
=> (defmacro do-while [condition &rest body]
       (while ~condition

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?
Yes. Thank you for the explanation.

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.
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. […]

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 -
                 args=[arg(arg='n', annotation=None)],
             body=[Return(value=BinOp(left=Name(id='n'), op=Add, 

Traceback (most recent call last):
"/gnu/store/b2cyhq822sywidaqnpg6kminvr34z9rq-python-hy-0.18.0/bin/.hy2py-real", line 
12, in <module>
 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.
Ok. Then there's not enough difference to justify hy-build-system.

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.

I guess java isn't a good language to compare as far as build systems go. There are several build systems commonly used for java, but there are only one or two python build systems, and they all seem to work the same way.
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,

Note that I said “Hy code compiles to Python (and vice versa :-))” which
is inaccurate; especially about the “vice versa”. ;-)

You cleared up all my confusion. Thank you.


reply via email to

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