From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add new lisp function length= with bytecode support Date: Fri, 10 Mar 2017 05:20:25 -0500 Message-ID: <3AD8FC51-ABB3-4FC7-A5EF-A30EBEA27E9E@raeburn.org> References: <64Kl8OYdaKer-3Ey7GHVD9He6bX8yYHaS_NjEwp7Wqc4Zb7xu8IQV3ExvjCLKlBWHVVr_HNUhd55i_BVXNHnpxjnXc6hPgWvWkc3bIO8e7s=@protonmail.com> <87shmy652f.fsf@linux-m68k.org> <-oad61IjWjfeUSwQ5oDR_0rzoc5JtVNOUzoEFCLeetTb9B29QSfWMUdprGdmeDMuyJt38l5W6NC97iCV0VLbBUGGF6K_6-lBf-t_N1_V6aA=@protonmail.com> <99375f4d-f627-8e29-2c1f-9d3bfdf3ddd1@gmail.com> <0mz3T7gRvLpYGD7MDAZGZjxUi5QdLAkXtZ7y8UX4a3tDMKu1KvlRZ2IYKRUlQh01TvDsPfG1Fl_l4MIlmBWtHW9A_nQ9liIx6Mz6vcT6lGw=@protonmail.com> <4pTgtp7P0udVYhXvmkdE96q4eNHNWW6ZQ1o7woPbQTJbXd5scmDTlaLrg4BtjD_YzTTX5qHyHhXUg3gX0jW5yenj-a2gnT0m8QiFQETB284=@protonmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1489141279 20635 195.159.176.226 (10 Mar 2017 10:21:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Mar 2017 10:21:19 +0000 (UTC) Cc: Emacs developers To: Gdobbins Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 10 11:21:14 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 1cmHfY-00047y-OE for ged-emacs-devel@m.gmane.org; Fri, 10 Mar 2017 11:21:09 +0100 Original-Received: from localhost ([::1]:38350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmHfd-0004nP-1p for ged-emacs-devel@m.gmane.org; Fri, 10 Mar 2017 05:21:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmHf2-0004mo-3Q for emacs-devel@gnu.org; Fri, 10 Mar 2017 05:20:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cmHex-0003Qc-6F for emacs-devel@gnu.org; Fri, 10 Mar 2017 05:20:36 -0500 Original-Received: from mail-qk0-x244.google.com ([2607:f8b0:400d:c09::244]:33337) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cmHew-0003Oh-Vz for emacs-devel@gnu.org; Fri, 10 Mar 2017 05:20:31 -0500 Original-Received: by mail-qk0-x244.google.com with SMTP id j127so26122587qke.0 for ; Fri, 10 Mar 2017 02:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QjH4ejGpLi7mve6CarkEPvn15kI6I07+FFCvN8VVX9Y=; b=p54isGorXhdfgfJHSgqe3+fcXsg18C0KhAylhBIsRmoj+EDPK/f3T4A5V5P4C6Pezw aWq77U4ZgigY/bGPeWRlif8eha05tDzV72VR6xZjAlvsuTCv/U0MkHxRn9t1ps0O8jrr gP6jitr53XKnHBg1IBv76BC3k9f8d4/HFU4x/QSLNo/X1+8DyqZ2f00cdAZM/NTRAK2E tu7DjHf8Gd3TRkUOQQCYKiY9oFv+DzXyXuGO1ln8ENCl41pAg1InSfhXUtMgpFtMeHno Ml2W6XzSdnaV3LJxPe8gLNQARWWCxHjJvDszL93mY0Ax2/g0gh7YwHNtdU4PaYLYvH8E OULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QjH4ejGpLi7mve6CarkEPvn15kI6I07+FFCvN8VVX9Y=; b=Jya5ojEkeVbfUIaRE0ceaAH2PoMhdvgxzwl/8ZcrccdzT24caP1100OKdxafHZOpRk rlmF/N1Ocv7U9KhXetggi3XxiKr15nyp7JPtMzJKN2gfGPD3s2+ARF/g6WHK0NOZxmQK PtYgGtNoUAhhgeF8dmXw/hf4BjoJJw1QQ2SeEIF7R/Z1be1Fqpqw+M5qkelCnUUVGIuR zmP1d283+asCzSqRBZuz83J03kK/tzkzilrkqUDZPaTJfkr0KiAfoRgnsNB+YmSAxoni X1axY6PYT6AuONdQcdOe5ZCuRynRnu8RTigMSjNJFzvl+CnhJi6gIEd2pJrKoZYKQnaR vB1A== X-Gm-Message-State: AFeK/H2zggGO+A50vGVdPqAX2xL+rQRU9W6LSXz1L2xlK0xUEIKmU4MJlQPjvs/o/m4Sag== X-Received: by 10.55.130.4 with SMTP id e4mr19165350qkd.65.1489141228596; Fri, 10 Mar 2017 02:20:28 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id v4sm6062506qtg.0.2017.03.10.02.20.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Mar 2017 02:20:27 -0800 (PST) In-Reply-To: <4pTgtp7P0udVYhXvmkdE96q4eNHNWW6ZQ1o7woPbQTJbXd5scmDTlaLrg4BtjD_YzTTX5qHyHhXUg3gX0jW5yenj-a2gnT0m8QiFQETB284=@protonmail.com> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::244 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:212875 Archived-At: On Mar 6, 2017, at 19:29, Gdobbins wrote: > Attached is a new patch which implements length=3D and the <, >, <=3D, = >=3D variants in lisp. They aren't as efficient as the length=3D from = the previous patch, especially in cases like (length=3D list1 list2). = Since these functions can't share a bytecode with their non-length = counterparts I don't know whether the trade off of a compiler macro for = them is worth it. With the lisp functions the resulting bytecode would = be both larger, and if none of the sequences are lists, slower as well. >=20 > -- Graham Dobbins Looks like interesting work. A few comments: The &rest arguments for the functions might be better called = =E2=80=9Csequences-or-numbers=E2=80=9D, because the documentation as = displayed by describe-function will show the parameter names. > length< is a Lisp function in =E2=80=98/private/tmp/gdobbins.el=E2=80=99= . >=20 > (length< &rest SEQUENCES) >=20 > Compare the lengths of sequences with numbers. The documentation indicates that numbers are permitted in the argument = list, but nthcdr won=E2=80=99t be happy with 3.0, or 3.1416, or = 1.0e+INF, or 0.0e+NaN. The tail-compare-or-swap and tail-adjust logic is hard to follow = (especially with no comments). Maybe it would be more straightforward = to just have the macro check if the comparison symbol is =3D and do one = thing, or < to do another, etc. Maybe even two different = implementations, one for =3D without the tail-adjust bit and one for < = and <=3D with it. And the functions working by argument list reversal = can just be their own functions, or use an entirely separate macro. I gather internal--length-compare (specifically the nthcdr bit) works = for =E2=80=9Cless than=E2=80=9D but not for =E2=80=9Cgreater than=E2=80=9D= , and thus the reversal approach is actually required, not just a way to = reduce the quantity of code generated. Is that correct? The doc string for =E2=80=9Clength<=E2=80=9D talks about wanting its = first argument to be a non-list. I take it that=E2=80=99s because it'll = always compute the length of a list in that position. But I think (length< some-big-list 5) could still limit the work it does by using nthcdr, couldn=E2=80=99t it? = Implement it the same as: (not (length< 4 some-big-list)) At least, when the number is known to be an integer. I think it=E2=80=99s if both arguments are lists, that=E2=80=99s when = you=E2=80=99re still stuck getting the real length of at least one of = them. (More than two arguments gets more complicated, but there are = additional use cases where unbounded =E2=80=9Clength=E2=80=9D calls can = be avoided. I don=E2=80=99t know if the case of more than two arguments = comes up often enough to bother.) The doc string=E2=80=99s attempt to refer to arguments that could be = sequences or numbers, and which get treated differently depending on = which they are, is a bit awkward. Maybe something like: Compare numbers and lengths of sequences. Arguments that are numbers are compared directly; for sequences, their = lengths are used. Return t if each number or length is `>=E2=80=99 to the next. I=E2=80=99m still not wild about it. Constructing a sentence from the = comparison-operator=E2=80=99s symbol name is just going to be awkward, I = think, compared to the doc strings for =E2=80=9C>=E2=80=9D or = =E2=80=9Clength=E2=80=9D which sound fairly natural. It=E2=80=99d be = better to actually write out =E2=80=9Cgreater than=E2=80=9D and such. The doc string mention of =E2=80=9Cmore efficient=E2=80=9D is ambiguous; = more efficient than what? Are you comparing against using =E2=80=9Clength= =E2=80=9D and =E2=80=9C>=E2=80=9D? Or are you comparing different ways = the arguments to the function might be arranged? Ken=