From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add new lisp function length= with bytecode support Date: Wed, 08 Mar 2017 11:47:51 -0500 Message-ID: References: <_Va7JCNtNKbVk4Ny13mMvZV7vv7_mFkIgMV2kPJGqlqrSV_XBS2tYZJWixctC4j4c4a4FpeTrpeSpqahEVbKHZyoGCgL4eaZZW1RtCHSnKU=@protonmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488991696 5918 195.159.176.226 (8 Mar 2017 16:48:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Mar 2017 16:48:16 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 08 17:48:12 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clel1-0000uz-9y for ged-emacs-devel@m.gmane.org; Wed, 08 Mar 2017 17:48:11 +0100 Original-Received: from localhost ([::1]:57279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clel7-0006RZ-5H for ged-emacs-devel@m.gmane.org; Wed, 08 Mar 2017 11:48:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clel0-0006RH-6N for emacs-devel@gnu.org; Wed, 08 Mar 2017 11:48:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clekx-0000zi-18 for emacs-devel@gnu.org; Wed, 08 Mar 2017 11:48:10 -0500 Original-Received: from [195.159.176.226] (port=33970 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clekw-0000zK-QO for emacs-devel@gnu.org; Wed, 08 Mar 2017 11:48:06 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1clekk-0007qV-1T for emacs-devel@gnu.org; Wed, 08 Mar 2017 17:47:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:dVvYeiosKpeF0KIMz9HuMP1ws4s= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212841 Archived-At: >> I think it's better to take >> your change upfront: make an incompatible change to `=` such that >> `length` is automatically called on each argument if it's a list. > That's a judgement call I can't make. I will point out though that it is > more incompatible than the change I've proposed, since there wouldn't be any > way to get the old behavior back (even if it took recompiling). Indeed, it's a bit more incompatible. But it's easier to describe the incompatibility: in your case it occurs in some cases and not in others, depending a whether something is byte-compiled or not and with which Emacs and which value of some fairly obscure compilation flag. > Personally I would think coercing sequences to their lengths in = > would be even more confusing. Could be, indeed. But in any case, that's what your code does, so better be prepared to defend this choice ;-) >> Furthermore, this could be seen as an improvement for package authors >> (by making `=` more powerful), so it has merit regardless of whether or >> not it makes a measurable difference to efficiency. > I guess, but is it really any more powerful than a separate length=? I don't know. I didn't mean to promote this change. I was just pointing out that (as maintainer) I'd be more willing to accept such an upfront change, than one that introduces an incompatibility in more sneaky ways. I'm not sure I'd accept either of them. > Since it's being discussed, a single new bytecode should be able to > encompass all of the length=, length<, etc. functions if it's decided to go > that route. As I've stated previously around 50% of all calls to length are > then fed straight into =, <.>, etc., so it may be worth it. That might be a better option, with more visible effects. The issue is that bytecode space is limited (and very difficult to recover later on), so I'd be reluctant to add new bytecodes without some clear benefit. So some real-life measurements of speed up would go a long way. Stefan