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

[Jesse Gibbons <jgibbons2357@gmail.com>]

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