From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] seq.el: add seq-last for symmetry with seq-first Date: Tue, 14 Mar 2023 16:14:18 +0000 Message-ID: <875yb3cntx.fsf@posteo.net> References: <871qlrmr14.fsf@gmail.com> <87fsa7cq0v.fsf@posteo.net> <87wn3jl4f8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?B?TWF0w7rFoQ==?= Goljer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 14 17:14:35 2023 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 1pc7IJ-0003rw-By for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Mar 2023 17:14:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pc7Hl-00087y-2w; Tue, 14 Mar 2023 12:14:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pc7Hj-00087m-LO for emacs-devel@gnu.org; Tue, 14 Mar 2023 12:13:59 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pc7Hh-00059i-Ha for emacs-devel@gnu.org; Tue, 14 Mar 2023 12:13:59 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 651AE240594 for ; Tue, 14 Mar 2023 17:13:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678810435; bh=1bMZVv33i8ccRKnXdHhWP2GXKG3bHBxO9AO/Gvd+XZE=; h=From:To:Cc:Subject:Date:From; b=lYkpxgcya+no0IPaRYfCYhaZn+UehmfF/+I0P4S0jL+w0AOgEnzVgQ4o2GjU9Cnlw G3FvKIy0IJMnGV5hxl8kUs1UHDMHe944wcDcZirxvz2FuJoo25N1Sj0XBGPpAI6TYm ASYHs+ENnxrJt5xXQGnCCO7dCUJPLw7l8dukC/KsSCcPuSA3Dm/3fZuiDgv0/Oi5N+ UVhe7floYP4wyK7sfQphTq6lt3mt8wRCOumIfJMwSXAkOS2JWWT2f3QjGV7wHyUU/+ QPfh1kGnMBnsr9f/MgJvSkPiNQA8+n/35Lvnu1DMViD+E2ryPw14Hz6IFXUyHmwsTb xccNfYA7YDTyA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pbdr26JY7z6tmS; Tue, 14 Mar 2023 17:13:54 +0100 (CET) In-Reply-To: <87wn3jl4f8.fsf@gmail.com> (=?utf-8?B?Ik1hdMO6xaE=?= Goljer"'s message of "Tue, 14 Mar 2023 16:48:43 +0100") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304449 Archived-At: Mat=C3=BA=C5=A1 Goljer writes: >> Wouldn't it make sense to add a specialised implementation for lists, to >> avoid recusing the list twice. > > I can turn it into defgeneric with default implementation same as what I > provided and special instance for a list, that makes sense. Although I > wonder what the performance impact is of the dispatch vs iterating a > list /shrug. That would be worth investigating, but considering that your proposed implementation would already have two dispatches (seq-elt and seq-length), I don't think this will be much worse, especially when the sequence becomes longer. >> A thing I notice is that seq-first is not consistent on the way it >> behaves if the sequence is empty. >> >> (seq-first '()) ;=3D> nil >> >> while >> >> (seq-first []) >> >> raises an error. seq-last would have the same issue for vectors, except >> that it would attempt to index the position -1, which might be >> confusing? > > I think for lists it should behave as `nth` or `elt`, so it gives nil. But why? Wouldn't that be a leaky abstraction, since the behaviour doesn't consistently abstract over the concrete sequence types? If code doesn't want to worry about what sequence is being used, then it has to manually check the return value or if a signal was raised, depending on the type of the argument to seq-last (which is to ignore the issue that we cannot distinguish between (seq-first '()) and (seq-first '(nil)), the same also being the case for seq-last). > I agree that the error with -1 for vector might be confusing. Should we > instead raise our own (seq) error for empty vector with seq-first and > seq-last? Not sure what would be the best way. I believe this would always be better, even for seq-first, though it might be that too late for that? > I should also add some tests, I've noticed there was a test file for > seq. Should I resubmit this patch with the feedback incorporated to > bug-gnu-emacs@gnu.org instead? I'm not sure if emacs-devel is the > place, sorry T_T. IIRC patches should be sent to bug-gnu-emacs@gnu.org, but emacs-devel is also acceptable if there is a need for discussion. I think the points I raised above would be worth a general discussion on how seq is to be used, which is not the matter of a single bug report.