From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QC8NLvuuH18tKAAA0tVLHw (envelope-from ) for ; Tue, 28 Jul 2020 04:52:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id eDkGKvuuH19VSwAA1q6Kng (envelope-from ) for ; Tue, 28 Jul 2020 04:52:11 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1411894062D for ; Tue, 28 Jul 2020 04:52:10 +0000 (UTC) Received: from localhost ([::1]:39564 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k0Hay-0000mQ-8O for larch@yhetil.org; Tue, 28 Jul 2020 00:52:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35882) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k0Has-0000m7-CO for guix-patches@gnu.org; Tue, 28 Jul 2020 00:52:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k0Has-00082T-2J for guix-patches@gnu.org; Tue, 28 Jul 2020 00:52:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k0Has-0006IE-0D for guix-patches@gnu.org; Tue, 28 Jul 2020 00:52:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#42456] [PATCH] gnu: Rename python-hy to hy. Resent-From: Jesse Gibbons Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 28 Jul 2020 04:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42456 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: zimoun Cc: 42456@debbugs.gnu.org, Brett Gilio Received: via spool by 42456-submit@debbugs.gnu.org id=B42456.159591186524116 (code B ref 42456); Tue, 28 Jul 2020 04:52:01 +0000 Received: (at 42456) by debbugs.gnu.org; 28 Jul 2020 04:51:05 +0000 Received: from localhost ([127.0.0.1]:56927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k0HZw-0006Gt-Ln for submit@debbugs.gnu.org; Tue, 28 Jul 2020 00:51:05 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:46319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k0HZq-0006GK-Ej for 42456@debbugs.gnu.org; Tue, 28 Jul 2020 00:51:02 -0400 Received: by mail-pl1-f193.google.com with SMTP id k13so1448217plk.13 for <42456@debbugs.gnu.org>; Mon, 27 Jul 2020 21:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FmKY1GMmrDWRHf+LN6KtmcFmOP9iq7PwOpX0ThCb1ro=; b=Tfk5PF7hQ6l1HwS7dpQo4m+xAGz7PGT5AkB7KViIoUYtjVSyFtVaHiytW/qtDB6mp0 newHBW9oj4045PMdhKUIjwUglJ1BY8sMkwiuFsZyH3wdSaPbxQRB6Yte1ESv+PNwfByD k4AOlBoggGJRMyGg0tQuxEmluMMRU2432Rk34u+nsj0aqiTg72Z1NxMtxS5nJOebJ7A3 YTotbmtVQE6ANG/vW7pV4itm4WFc86t8P0Gn5bqNzEygxxPUKAmgXzMOY3KBa0wQ3pv2 kwijTFZ6khNDyBWkCDurPUrUSA8x891fQJb4vbebEInfZRMpuzevq3xIg2pkCvOt7Ext mxFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FmKY1GMmrDWRHf+LN6KtmcFmOP9iq7PwOpX0ThCb1ro=; b=aAb+MIM78Eb228axVXKoyHZ6FmIwWH+7f2/tbEEG4J5hvuVJ1niAjbKcosnHsF2w+v hpzkIhsiEwABw/JxgU3+yr/1ZdJx6TMIU9KApsafqc5w4gllEf3NmZZqfDaszbRKsqJj YhkKWJGszzkpHs/EpUhBMubSeQgq+iLk2ImdPy8FVE2lzWEPvfxEYV5vkek4kY++eGLw LESGDNieejM1DTxJ7vF/VY/IwyV99BEVRfupBZvLP3obf+9HjCQTJ3rvipVuBCAyhJRd oScjvm/1g1HQV+4rnCGddLPqKuTD6KrfJZDs15vfDwqj6kKWolXJI7Ee0V3kLx+VWZOh gnjA== X-Gm-Message-State: AOAM532/SWcS0eh5UTDL3nrr0kr7fp9AtLQGFgQdNM0A6fhvbD2FdOzs 1ohARM0GSX/52JA9jUynngRIxlk5hj0= X-Google-Smtp-Source: ABdhPJwTSyfG8B2RNC8xQheLW/tVD0SO6VYzSyd+2P+CaPRFlrSh4tN0M4tYk7197MqjMobj7/3kfw== X-Received: by 2002:a17:90a:65c7:: with SMTP id i7mr2523185pjs.103.1595911851916; Mon, 27 Jul 2020 21:50:51 -0700 (PDT) Received: from [192.168.1.25] ([38.141.58.134]) by smtp.gmail.com with ESMTPSA id u23sm16493536pgn.26.2020.07.27.21.50.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2020 21:50:50 -0700 (PDT) References: <1dc02d59-c67b-2002-6a99-ceb0cdc24645@gmail.com> <87a6zo5rdq.fsf@gnu.org> <08f72489-fb0b-c367-ff9e-6cb3beb4e127@gmail.com> <86k0yoz8m6.fsf@gmail.com> From: Jesse Gibbons Message-ID: <378c3b08-6311-8f33-5fb3-25266700b038@gmail.com> 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 MIME-Version: 1.0 In-Reply-To: <86k0yoz8m6.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.6 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=Tfk5PF7h; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: IYLO0Ukpuibe On 7/27/20 8:17 PM, zimoun wrote: > Dear, > > On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons 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])])) > > > --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 > 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: > --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