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

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

[Jesse Gibbons]

* gnu/packages/python-xyz.scm: (python-hy): Rename to hy.
---
gnu/packages/python-xyz.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 748f48f229..e1b16f9c23 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -9961,9 +9961,9 @@ with a new public API, and RPython support.")
(define-public python2-rply
(package-with-python2 python-rply))
-(define-public python-hy
+(define-public hy
(package
- (name "python-hy")
+ (name "hy")
(version "0.18.0")
(source (origin
(method url-fetch)

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

[Jesse Gibbons]

I initially created this patch thinking hy is primarily an application. 
I brought this up in the IRC, and was told to send it and discuss it here.

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

[Brett Gilio]

Jesse Gibbons <jgibbons2357@gmail.com> writes:

> I initially created this patch thinking hy is primarily an
> application. I brought this up in the IRC, and was told to send it and
> discuss it here.

Hi Jesse,

I think if we rename Hy (and subsequently break the python-* naming
convention) we should justify moving Hy perhaps to its own module. I am
not overly familiar with Hy, I know that it uses and is compatible with
Python libraries (as Hy is mostly just sugar on-top of the Python
runtime) but do Hy-specific libraries exist? If so, I think that would
make the case for moving Hy to its own module even stronger.

Brett Gilio

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

[Jesse Gibbons]

Though I do not know much about hy, I do know the following:

- There are some libraries written in hy[0].

- There are tools written in hy specifically designed to handle hy.[1]

- Some hy libraries contain macros that I don't think compile into 
python. It looks at first glance like hyclib[2] and hyiter[3] are 
examples of such packages, though I have not confirmed.

- The libraries and programs I have found written in hy look like they 
would use python-build-system. If we see patterns in defining these 
packages, we can always provide a hy-build-system for convenience.

[0]https://libraries.io/search?languages=Hy

[1] https://libraries.io/github/hylang

[2] https://libraries.io/pypi/hyclb

[3]https://libraries.io/pypi/hyiter

On 7/24/20 7:13 PM, Brett Gilio wrote:
> we should justify moving Hy perhaps to its own module. I am
> not overly familiar with Hy, I know that it uses and is compatible with
> Python libraries (as Hy is mostly just sugar on-top of the Python
> runtime) but do Hy-specific libraries exist? If so, I think that would
> make the case for moving Hy to its own module even stronger.

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

[zimoun]

Dear,

On Sat, 25 Jul 2020 at 17:45, Jesse Gibbons <jgibbons2357@gmail.com> wrote:
>
> Though I do not know much about hy, I do know the following:
>
> - There are some libraries written in hy[0].
>
> - There are tools written in hy specifically designed to handle hy.[1]
>
> - Some hy libraries contain macros that I don't think compile into
> python. It looks at first glance like hyclib[2] and hyiter[3] are
> examples of such packages, though I have not confirmed.

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 :-)).

> - The libraries and programs I have found written in hy look like they
> would use python-build-system. If we see patterns in defining these
> packages, we can always provide a hy-build-system for convenience.

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. ;-)
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

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

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

[zimoun]

Dear,

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

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

[Jesse Gibbons]

On 7/27/20 8:17 PM, zimoun wrote:
> Dear,
>
> On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons <jgibbons2357@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?
Yes. Thank you for the explanation.
>
>> 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.
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,
> simon
>
> ps:
> 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.

-Jesse

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

[zimoun]

Dear,

Without going too far from the initial thread topic, Hy asks a good question.

> Ok. Then there's not enough difference to justify hy-build-system.

The question is how to switch the Python VM and still keep consistent
packages.  Well, related to this discussion:

  https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00115.html

And Hy could a nice test-case.


All the best,
simon