From: zimoun <zimon.toutoune@gmail.com>
To: Jesse Gibbons <jgibbons2357@gmail.com>
Cc: 42456@debbugs.gnu.org, Brett Gilio <brettg@gnu.org>
Subject: [bug#42456] [PATCH] gnu: Rename python-hy to hy.
Date: Tue, 28 Jul 2020 04:17:05 +0200 [thread overview]
Message-ID: <86k0yoz8m6.fsf@gmail.com> (raw)
In-Reply-To: <d6d5bf12-7bbf-c5e0-ffb2-56c7da89bc7f@gmail.com>
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”. ;-)
next prev parent reply other threads:[~2020-07-28 2:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-21 6:09 [bug#42456] [PATCH] gnu: Rename python-hy to hy Jesse Gibbons
2020-07-21 19:26 ` Jesse Gibbons
2020-07-25 1:13 ` Brett Gilio
2020-07-25 15:44 ` Jesse Gibbons
2020-07-27 14:40 ` zimoun
2020-07-27 23:05 ` Jesse Gibbons
2020-07-28 2:17 ` zimoun [this message]
2020-07-28 4:50 ` Jesse Gibbons
2020-07-28 9:51 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86k0yoz8m6.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=42456@debbugs.gnu.org \
--cc=brettg@gnu.org \
--cc=jgibbons2357@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).