From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: akater Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add cl-map-into Date: Wed, 29 Sep 2021 19:30:44 +0000 Message-ID: <87czornpqz.fsf@gmail.com> References: <87h7eag90n.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4694"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 29 21:43:37 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 1mVfUN-0000uq-Rq for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Sep 2021 21:43:35 +0200 Original-Received: from localhost ([::1]:40688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVfUM-0004IF-HP for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Sep 2021 15:43:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVfTJ-0002wt-6B for emacs-devel@gnu.org; Wed, 29 Sep 2021 15:42:29 -0400 Original-Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:42689) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mVfT8-0003uA-7E for emacs-devel@gnu.org; Wed, 29 Sep 2021 15:42:28 -0400 Original-Received: by mail-ed1-x536.google.com with SMTP id bd28so12710046edb.9 for ; Wed, 29 Sep 2021 12:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=6m863dZHDjlM1j16XDgrvdzFsAV34HcRGtdvxIWowP8=; b=qWP2utehqBT9aUsFC2+AuDkPbyOPt5NX+CeZtmleEFh5YezEN5ECZJM64Nnq+bqYiB UB/lL2cQNRvIy2UR2gXzKpmXpzxki3lML01gThJS6u5+GWgNOTt9aFm4C0laVFgyW9R7 BrLDNeZ3YVF5IP24sVuk2tFDsLS5jIZmvbbqI0XOdcrqXeVO1RC/J3o7LrnfRJGkpetO O9Tk7lrjxRt9ZbkZR3fZ31jK569Ac98ZzbbGBcZPl6AKrVBp2vodzXdi8bib6rYU+nau spU+7oYDJRaTEtlBEVjOmXAg6N8r9h4bBtniODWEE/eUCcO5Tovg0bZyvXSRqvZVu/UM Fqiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=6m863dZHDjlM1j16XDgrvdzFsAV34HcRGtdvxIWowP8=; b=OMg/wyRoUAqYKGPAqBMhFEOEu9uK1OIHb/24MTClPBhKRC7B59fqopw9vF3y8XOHcV iSuWIOCxMkBgggT539qmj3UXp2NoB6ZxQji9o9nKQB2BtMpI2JEwssSHgAgc6tJuu87I 2rR0WZfNPjXAkczrZmIZBNq4dJgTSSFRfXe0X0h0dTVSc6ILd64pW2yXM8EWuoQ6CBkT H+64Mpnsnu+QpLzIOYvea7DkcjsqChCPMKdmmtLddf4mMXvcud31AJbVnINsTsaoV8Hm CIoCIJkm1H8PWa1lHaQ/Yvo4c26G/01rdUqESkKJVWCpF+Rhd/73fojmuykOJHJP4Uxt wArw== X-Gm-Message-State: AOAM532ndpmzdN3h2ApLum+shBChACgFcOBNwHC8X0hZzlY53vfwAawU imCxsq+DcGViLs1G2IJAMaM= X-Google-Smtp-Source: ABdhPJwaZ57Du/kqHp+ruNsagW+76NwOTBSNfANn8D7ml4WNwQf5N7SXU+nWq1rrsRKTKF5CtxIaVw== X-Received: by 2002:a17:906:1615:: with SMTP id m21mr1910598ejd.279.1632944536963; Wed, 29 Sep 2021 12:42:16 -0700 (PDT) Original-Received: from localhost ([45.153.160.138]) by smtp.googlemail.com with ESMTPSA id s15sm445838edu.91.2021.09.29.12.42.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 12:42:16 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=nuclearspace@gmail.com; helo=mail-ed1-x536.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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:275828 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: > - Could you provide some corresponding tests for test/emacs-lisp/cl-tests= .el? There are some tests in comments; I'll make them into proper tests and add some more. > (cl--generic-with-memoization > (if small > (aref cl--map-into-mappers-array sig) > ;; TODO: Order alist entries for faster lookup > ;; (note that we'll have to abandon alist-get then). > (alist-get sig cl--map-into-mappers-alist nil nil #'=3D)) > (cl--make-map-into-mapper sig)) I didn't now there was (setf if). Good, I'll use it. Only it would be confusing to make cl-extra dependent on cl-generic. with-memoization better be in cl-lib proper which is also suggested in my cl-flet patch (the big one). I was unable to move it out of cl-generic into cl-macs =2D-- Emacs failed to build when I moved it and made an alias in cl-generic. Do you agree it should be moved, at least for the sake of cl-map-into? Actually, I think it could be =E2=80=9Cpublic=E2=80=9D rather= than --'ed. Just make it with-memoization in subr-x or some other file that is commonly required at build time, why not? > - Since we're (weakly) promoting seq.el over cl-lib.el, I wonder if you > think it would be worthwhile to try and do something similar in seq.el? None of seq- functions accepts arbitrary number of arguments so I don't see how this particular dispatcher would be useful for seq.el. However, this is an interesting topic. seq.el was recently rewritten in terms of cl-generic which in my view was wasteful and overall unfortunate. I recently came to conclusion that CLOS should only be used when method combination is used significantly. This conclusion is not shared by Common Lisp veterans in #commonlisp at libera.chat which is the first time I disagree with Common Lisp veterans on CL. But still, it is not very surprising; looks like method combination has been underappreciated since its inception. seq- does not define a single class and I don't see how any of the methods it defines could be conceivably combined with any other methods imaginable. That means, all the intricate dispatching powers of CLOS are just wasted on seq.el. Not only that; using CLOS introduces (for no reason since inheritance ends up unused, with no prospective use cases in sight) limitations on what seq's dispatchers could possibly do. CLOS' dispatch is tailored for combining code by means of inheritance. That means, types that can't be classes (i.e. types that are incompatible with =E2=80=9Cmost-specific=E2=80=9D / =E2=80=9Cleast-specific= =E2=80=9D ordering) are out of service. If one needs an interesting method for a type that can't be a class (true for numeric ranges, for most of what modern compilers do, you name it), one simply can't have it. To conclude, I think seq would benefit from a different dispatch mechanism that is not shoehorned into it. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJLBAEBCgA1FiEEgu5SJRdnQOF34djNsr6xYbHsf0QFAmFUvuQXHG51Y2xlYXJz cGFjZUBnbWFpbC5jb20ACgkQsr6xYbHsf0SjQQ//cpqFdx1v3HAh5sIG7n9WYI+G gFFrz4PODTBdFw5pzSwyyT1K7ApheV8RaFfpEjGcUedBPJyoxjq9PFL5QHyMy3TQ vnOzY4SrkAgoIwwlDYyFU4zV9KcqswhD5q7ac6heHDICsENUDbbWUPvISMRNf6D8 8/wU8pixyvT4jpPwuxctwNxebrPC45S/tDL2AKtP6iAuvkQsBvOSODGwzeD0Jd3f 3vYeXVVvYi0uWgX4KINuY7NtDy61oIthQV6QiAAjGzuHXNGPFdNI4FQexr1RGoxR hrgN4DJs/T/btTHiWrA8Vl0v/1v9UyR8nxGol7JQuC2Ig6wrUjMn1DA9tkGx5AOj wwKVAKOSh24sTJYyyCxHICxk7QS8KuTpRCst6HoVzuqg8QCx6PmhktuoETa0r5qh /Uqr5z5X7CWjYCVb6zvWnietuM224qIa6FodzrSoGLdXHSgzAWxlVymC32ISFgCX mgND+jEFUdW2m4Ndzv+szAp3su6LvbWAn0AYcnOPwcBT8MfCB0KIKfnR4Jurt8Dq eAl9e9jlW97n4yDaSWWU421xHo7JXn/QlO6yiGYsrEKu3QRBso/40B/HZ+FAfZkp T3+Va7h3WlvyiPVp2HxXOgPa/L9NWKTemk7RkVhciis0TICHZAaRSUBfQFn6XNRk lboqNEhZEzB7Y90nTx4= =1kY7 -----END PGP SIGNATURE----- --=-=-=--