From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Always-true predicate? Date: Fri, 19 Feb 2021 10:07:10 -0500 Message-ID: References: <875z2qoqc6.fsf@gnus.org> <87h7ma25so.fsf@tcd.ie> <8735xu33jy.fsf@gnus.org> <87lfbm1o5s.fsf@gnus.org> <874kiaxxbs.fsf@iki.fi> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21226"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 19 16:49:08 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 1lD81k-0005QH-Ej for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 16:49:08 +0100 Original-Received: from localhost ([::1]:51988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD81j-0003IU-CG for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 10:49:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD7NG-0002bJ-Sj for emacs-devel@gnu.org; Fri, 19 Feb 2021 10:07:18 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42913) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD7NC-0003GP-Q0 for emacs-devel@gnu.org; Fri, 19 Feb 2021 10:07:18 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0A23F1000CF; Fri, 19 Feb 2021 10:07:13 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4649B10022E; Fri, 19 Feb 2021 10:07:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1613747231; bh=jaP2GpfskplQsfJpsaMExCyfWudGQZT50sflZ6a2uU4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=EQjVIZuDFfXdV5denVZ4I+g0Ka75gu5k0iGAH+6lfRPB2DCEBFmAKjWvX3jrLtqmp rOz9pTr7dYZSaGY9kZBjzx/lHSMwOBFgdcC3PuCKfFTxs4Lu5gBcFtZMr0nbR8N+Oq to4Vo6A82qPbiwzn5hBSYzc3cLVk0R2Cbx9pjLtoL47YZthDjZt2sic8zwc45IuJ35 WAd8hi+BsziyjeU4y2RFSovlkqHFMapyQdb7+C9TLBCBS7jS0ITKsnVGDsVUftYnqZ y5zVNFyr1dcKgiVT3/JwbtBUFhrB7kS5PJHiRPaF7FhYRPxsJZEfMxd561e7QytbxT s243dp8u8DqWA== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EDDD4120198; Fri, 19 Feb 2021 10:07:10 -0500 (EST) In-Reply-To: (Pip Cet's message of "Fri, 19 Feb 2021 11:27:52 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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:265265 Archived-At: >> > Seriously: I remember one case when I tried to find CONSTANTLY or >> > similar but failed. I wrote some LAMBDA form. No big deal. >> Maybe we should let `lambda` take arguments like Scheme does, i.e. >> (lambda (a b . c) FOO) instead of (lambda (a b &rest c) FOO), and in that >> case we could simple use "lambda _" as a shorthand for "constantly". > That would break things like pcase-lambda, though: we would no longer > be able to generalize lambda meaningfully. [ Not sure if you missed the implied smiley or if you're going along with the crazy idea. ] `pcase-lambda` wouldn't have to follow suit, so it'd be affected only if it decides to. > Anyway, my problem with variadic functions isn't defining them, it's > calling them. I think I should be able to say > > (f a b c &rest d) > > rather than > > (apply #'f a b c d) I don't think it's sufficiently nicer to justify making such a change, but yes, it would make it more clear when apply is used to call a known function. OTOH, the nice thing about `apply` is that it's just a function: no special treatment, no new syntax, nothing. Try `grep apply lisp/emacs-lisp/bytecomp.el` and see how it really needs no special treatment. > (f &rest a &rest b) = (apply #'f (append a b)) > > and > > (f &rest keywords values) = (apply #'f (zip keywords values)) I find the left hand side worse than the right hand side, FWIW. I'd rather reduce the use of `&rest` and `apply` than try to make it more sexy, since it's fundamentally quite inefficient (since it ends up having to take the list of args, put them on the stack only to recreate a new list for them on the other side; in theory it can optimized in many cases, but in practice it's extremely hard to find those cases reliably). > And if we can require optional arguments, why can't we provide them > optionally? For example, let's say in Emacs 33 we want to expand > copy-marker with a new argument to more clearly describe how the > marker repositions itself relative to other markers (or implicit) > markers at the same character position. But (copy-marker marker nil > &optional 'something) would work in Emacs 32 (which would include the > optionally-provided argument extension), and be equivalent to > (copy-marker marker nil) there. This seems difficult to make it work reliably. E.g. imagine the case where you've added an advice to `copy-marker`, so it's now redefined to (lambda (rest args) (message "About to call copy-marker") (apply # args)) how would the caller know whether it should pass that `&optional 'something` ? I can see ways it could work, but I can't see an easy way to get there from where we are without introducing either a lot of extra complexity (and runtime cost) in the implementation, or backward incompatibility for some use cases, or both. Stefan