From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: defmacro with built-in gensym declaration and initialization Date: Wed, 20 Jan 2021 20:55:46 +0000 Message-ID: <87o8hj9vl9.fsf@tcd.ie> References: <87bldk6n2l.fsf@gmail.com> <87turbiuvr.fsf@tcd.ie> <878s8n76ih.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17407"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: akater Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 20 22:03:46 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2Kdl-0004R9-P9 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 22:03:45 +0100 Original-Received: from localhost ([::1]:48198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2Kdk-0002d1-PS for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 16:03:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2KWA-0005xB-8z for emacs-devel@gnu.org; Wed, 20 Jan 2021 15:55:54 -0500 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:43726) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l2KW7-0006ab-DG for emacs-devel@gnu.org; Wed, 20 Jan 2021 15:55:53 -0500 Original-Received: by mail-wr1-x436.google.com with SMTP id b5so1641545wrr.10 for ; Wed, 20 Jan 2021 12:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=opAIzIAfJhlIDwvIoeNl5OumbAnorOExDEygFcnL+DI=; b=TuEH6O+YumXSMxZMFmWmx31tf5whidkSMSTrauv+jwZCcIMvFVigWmsU6GfhkfuuFm u6i58I5gr8FXLmlGSHUM1SM+pfJjPpTWUJiozWUf8W0Ap0wAdDu7xaI2s0OAdff13Hmd cBMtDVhQyaialydcwoqnKKHSu0ilYTVXmhVRk7/jvwM7YqB1QcslwyGA0RUWiZD4E8SX dVw07+F4XZ7vqHLBJhzDc2ehDziBUkSUfO87vMTV/IqONqEbCc1o5+jxEewu9Lg/L+5d plXFCAiAYIugnTiaZg4Opv6PK2vh92hMSTN1BfMAibRar3/IL9ZV1F2Ud+em6r7F4uzv RvVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=opAIzIAfJhlIDwvIoeNl5OumbAnorOExDEygFcnL+DI=; b=t2kr1mw8YnIBfRPw52SOwgYcwiY7IE+q4+MxV9qhR4jp44oBCciX7AwL+Vq0CQ5Ekg tzHmRZOha94YsRwWkojmj6UerR7LiPKf9auV8Y0hvu2849BxIMDRy+RXqzpkXLDTCc6F SID7PQSBtCnIX8ZJ0kMY9+vVKZUKtt0UYrewQXTDSr6tkO+VkSjtIoUQGC4gn9lwUVSU F9FdH3wD2Vf8KuniJ/xCtaodGynNIjbKBpFBeUdAaeMu1Q8pTTCqInN5E8SaJBgBBg+N 5SVQICBQ39QMm3IvJsSb3lpNi14qqj7ar490iAucz36x/qp1bpsr7aHdQ3IB3dm0eTUK nZ7Q== X-Gm-Message-State: AOAM531HbDohKSPowrYS33ko8H+HUjmvD9z874aD/RcNeiBLhTK/7PpM ib0YcMtUHQny6kOJcnmNVa4Nrw== X-Google-Smtp-Source: ABdhPJzJo3O3KUKG0wleJXuhhGXuJP/qTU8Vid22fyx+MMPPiRa+6ansYpqWYCvoLPfAeZDqF5iIlA== X-Received: by 2002:adf:fd10:: with SMTP id e16mr8985723wrr.376.1611176149323; Wed, 20 Jan 2021 12:55:49 -0800 (PST) Original-Received: from localhost ([2a02:8084:20e2:c380:6146:9c0d:a0ea:26d0]) by smtp.gmail.com with ESMTPSA id i131sm5474924wmi.25.2021.01.20.12.55.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jan 2021 12:55:48 -0800 (PST) In-Reply-To: <878s8n76ih.fsf@gmail.com> (akater's message of "Wed, 20 Jan 2021 19:28:06 +0000") Received-SPF: none client-ip=2a00:1450:4864:20::436; envelope-from=contovob@tcd.ie; helo=mail-wr1-x436.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263220 Archived-At: akater writes: > "Basil L. Contovounesios" writes: > >> IMO, this minor convenience is insufficient motivation for >> conflating/complicating a macro's global arglist, i.e. its arity, >> calling convention, etc., with utilities for its local body. Is there >> some other motivation? Am I missing something? > > My motivation mostly comes from CL where complicated lambda lists are > not considered an issue, and it didn't come to my mind it could be an > issue for Emacs Lisp users. In particular, &gensym does indeed follow > the design of &aux, described below as =E2=80=9Chideous=E2=80=9D (another= surprise). I'd seen &aux before but didn't look up what it does until now, and I must say I share Stefan's sentiment :). > I use &aux regularly, and I find it a nice addition as it reduces the > nesting depth of defun and defmacro forms. &gensym does that and saves > some boilerplate on top of it, I tried it in real life macros, found it > useful, and that's pretty much it. Let's just say I would sooner see native arglists gain support for keyword arguments ;). For non-native arglists, we could always extend cl-defmacro or some other definition definer. >> conflating/complicating a macro's global arglist, i.e. its arity, > > What's the arity of defmacro? This form already allows any number of > arguments so as far as I can see adding another keyword does not change > arity. Calling convention is backwards compatible. I was referring to the arity of the macro being defined, not that of defmacro. > Again, Common Lisp > implementations are allowed to introduce their own lambda list keywords > so I didn't (and still don't) think extending lambda-list keywords set > is a big deal. I can't imagine it being as little a deal in Elisp, but that's just my impression. >> Why not provide handy gensym/once-only local conveniences for macro >> authors instead (some of which already exist in one form or another, >> e.g. macroexp-let2, inline-letevals, and org-with-gensyms)? > > I don't have much experience with macroexp-let2 which on the first > glance looks like an overcomplicated once-only that is mostly relevant > for functions that are meant to be byte-compiled. It and its variant macroexp-let2* are relevant wherever the macro author wants to avoid evaluating an argument more than once, but improvements are always welcome. > Since we're moving to > natively compiled Elisp, I was thinking it's going to become less > relevant in near future, and &gensym covers most use cases of once-only. I don't see how native compilation changes how existing and new Elisp macros ought to be written. > Again, org-with-gensyms is precisely something that's being replaced > here with an alternative that is less verbose and has a decreased > nesting depth. Just my 2 cents, --=20 Basil