From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Always-true predicate? Date: Sat, 20 Feb 2021 09:40:38 +0000 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; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17909"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 20 10:42:21 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 1lDOmK-0004YT-JM for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 10:42:20 +0100 Original-Received: from localhost ([::1]:42722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDOmJ-0007kc-HW for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 04:42:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDOlJ-0007Io-JK for emacs-devel@gnu.org; Sat, 20 Feb 2021 04:41:17 -0500 Original-Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]:43477) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lDOlH-000101-Rf for emacs-devel@gnu.org; Sat, 20 Feb 2021 04:41:17 -0500 Original-Received: by mail-oi1-x232.google.com with SMTP id d20so8651667oiw.10 for ; Sat, 20 Feb 2021 01:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pOzMor1Nw+98fFZpt0y8LIW/ooqzNECcjfBOAW7nmG0=; b=Gp0dlRStX8TRs0Tu93/iQZkbmR5+U4Fk7WvRkjZXtbAYan7BK3tey+rGeL2n7ehdn/ AsxIX3xuveYPLvKg9elT52yA1Ufmiuv2cL1sDbQ4iE8kvF26swawmZfG63o0L6VPFt0b XjBqiJoybwEU4kD3uySzygMekjruH1peyJfxR9ZU77qP7v51uiYuxNK32ZNP/8vXNNA9 l+Kpd9NhUZ/V+lvmagk5u+3T9wDVMTiXHvwe938ZxHJs+FKqhTcGtXtXZYz1U/kuzErY bCxlDGl8AQ2B1VHLCHyzHoCATiV10XzKHUQ64I2dYXl9RNv2N12d3bfEQadi5meIOmL9 LoVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pOzMor1Nw+98fFZpt0y8LIW/ooqzNECcjfBOAW7nmG0=; b=tF5ZBwYM+eUheM+RboQYo/Pw4GEzxwd+NT+AO4/G88mWq9FH1UmKdHRqrHKlopqU8n do2OljsxjSI9ymtjL8iPy7jkR9ajNwHp3AMiNGYTqzmUYwy3v1awerCfOib0ZVwUF5gl 5fxx3c39Gsr77oBo+FoB9H+lQeDRUNSEin4n849+oK+F0KMCOC9meeYhijDr+Lo7KY8Y d2Thkbvr+rQ0IG1mFjsDSbrnEipijhY7cwe3Reg9U01imYe/ImE0iCX/ESQq6Bw3TN7N 5EtPuwc7+Ja1yjrI0uShugycAIYjJPx/nSZBOCxy/eNenA3tbIqtLC6vsfiaqQTe68Ze qhuw== X-Gm-Message-State: AOAM530/rVn5tU+JX+fa8tFqfcEGKps18r3vI4BWSLdffBAqD9Uc3bUu FWPo8HcNl+QV5V+IcxXgDFbk9qa2apQO5oXWv+M= X-Google-Smtp-Source: ABdhPJxm9fk8M1sPJr1DnBnrGDaMCbdJtmwxy8+mkAQz4bMn5r9773LdKGS4FNXO//CLQ/yt0JQNWRq6Y3bv+25UnTk= X-Received: by 2002:a05:6808:8e1:: with SMTP id d1mr9686484oic.122.1613814074673; Sat, 20 Feb 2021 01:41:14 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::232; envelope-from=pipcet@gmail.com; helo=mail-oi1-x232.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:265295 Archived-At: On Fri, Feb 19, 2021 at 8:11 PM Stefan Monnier wrote: > >> > (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, > > > > I think "usage mimics declaration" is a very important concept, > > I generally agree and the above syntax is indeed satisfactory from that > point of view (and funnily enough Scheme's neat (lambda (x . y) body) > syntax (which is arguably inspired by a similar desire) does not enjoy > such a nice equivalent at call sites since (f x . (append a b)) can't > be distinguished from (f x append a . b)). I discovered this the hard way :-) > >> 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. > > ...but it gets that special treatment, which is why (apply #'or) is > > mis-compiled. > > Actually, it's not the compiler, it's the optimizer. I didn't say "by bytecomp.el", I only said it's mis-compiled. Which it is. By the optimizer. Which is part of the compiler. > [ Yes, it's a nitpick, but nevertheless... If you think the optimizer isn't part of the byte compiler, please change the first line of byte-opt.el which says it is ;-) > Also, I'm not completely sure in which sense it "miscompiles" it, > since it can't be compiled correctly, AFAIK. ] ??? It's perfectly valid ELisp. It should throw. It doesn't. > >> I'd rather reduce the use of `&rest` and `apply` than try to make it > >> more sexy, since it's fundamentally quite inefficient > > I think the inefficiency is fundamental to "apply", not to "&rest". > > When you call a known procedure all the packing and unpacking of > > arguments can be inlined... > > IMO it's more fundamental to `&rest` because the callee can rely on the > `&rest` list being a fresh new list (it can safely perform destructive > update on it). So to avoid having to cons up a new list you have to know about the callee to know it doesn't do that, which apply prevents you from doing. > > I think we're back to a fundamental question here: if I understand > > correctly, to you, an ELisp function is fundamentally of the "take a > > list, return a Lisp object or throw" type, as though it were defined > > like this: > > > > (defan f args (if (/= (length args) 2) (throw > > 'wrong-number-of-arguments)) (+ (car args) (cadr args))) > > Indeed. Looking forward to your patch removing all argument names from defuns everywhere ;-) I'd like to know what equivalence relation you're using when you say two bare functions f and g are "the same". I'm pretty sure it's not any of the following: - their defuns are the same - they produce the same values for the same inputs - they produce the same values for the same inputs at the same complexity > > In your world, (lambda (&rest args) (apply #'f args)) is the same as > > f. In my world, we have "func-arity", to which it isn't. > > In my view, a function value of the form (closure ...) or (lambda ...) > or #[...] has arity, but a function value represented by a SYMBOL does > not because it can change at any time. In my view, every callable function has arity, which can change at any time in the case of functions that are symbols (which might become uncallable, too). (It can also change for closures or lambdas if their underlying lists are mutable). It seems obvious to me that if f and g are "the same", (func-arity f) and (func-arity g) should return equal cons cells. That means unless f is a subr of arity (0 . many), f is not the same as (lambda (&rest args) (apply #'f args)). BTW, I made a mistake in my previous email: (f a &rest b c) should be equivalent to (apply #'f a (append b (list c))). No zips, and no spreadification of the last argument. Pip