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

Previous Next

Full log

Message #23 received at 42456 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Jesse Gibbons <jgibbons2357 <at> gmail.com>
Cc: 42456 <at> debbugs.gnu.org, Brett Gilio <brettg <at> gnu.org>
Subject: Re: [bug#42456] [PATCH] gnu: Rename python-hy to hy.
Date: Tue, 28 Jul 2020 04:17:05 +0200

Dear,

On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons <jgibbons2357 <at> 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”. ;-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.