From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.devel Subject: Re: string> missing? Date: Wed, 3 Jun 2015 21:36:05 +0000 (UTC) Message-ID: References: <87oakxkvqw.fsf@petton.fr> <83zj4grgkc.fsf@gnu.org> <87sia8n8b5.fsf@petton.fr> <87zj4gu821.fsf@gnu.org> <83sia8rdkm.fsf@gnu.org> <83pp5crbfd.fsf@gnu.org> <83mw0gr4eh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1433367449 29494 80.91.229.3 (3 Jun 2015 21:37:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jun 2015 21:37:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 03 23:37:21 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z0GLM-0001nP-Rx for ged-emacs-devel@m.gmane.org; Wed, 03 Jun 2015 23:37:01 +0200 Original-Received: from localhost ([::1]:38354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0GLM-0000fQ-0v for ged-emacs-devel@m.gmane.org; Wed, 03 Jun 2015 17:37:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0GL3-0000dM-Dm for emacs-devel@gnu.org; Wed, 03 Jun 2015 17:36:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0GKx-0000GZ-2L for emacs-devel@gnu.org; Wed, 03 Jun 2015 17:36:41 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0GKw-0000Fk-Sm for emacs-devel@gnu.org; Wed, 03 Jun 2015 17:36:35 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z0GKg-0001ES-DK for emacs-devel@gnu.org; Wed, 03 Jun 2015 23:36:18 +0200 Original-Received: from rezo-156-5.ens.fr ([129.199.156.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Jun 2015 23:36:18 +0200 Original-Received: from thibaut.verron by rezo-156-5.ens.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Jun 2015 23:36:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 29 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 129.199.156.5 (Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187005 Archived-At: Nick Andryshak gmail.com> writes: > Having one comparison operator without the other is simply confusing to > developers. If I'm writing code where '<' exists and works, I believe > it's reasonable for me to assume that '>' will also. Apply this same > logic to string< and string>. > I did run into a similar issue not long ago, when I had to test for emacs version in my .emacs. It took me a few minutes to find out that no, version> doesn't exist. It left me with a bitter taste of waste, like some simplicity that was given up for no apparent reason. But I could see a possible reason for this missing function: version> and version< are not as symmetrical as they would seem, and writing code "for all emacs versions more recent than this one" is almost certainly going to break something in the future. What is understandable for version> seems to be nonsense for string> though. In this case, the functions are symmetrical, why have one and not the other? And about the additional string<= and string>=, I'd say these are even more useful, because testing strings for equality in emacs lisp is already tricky enough! And, it is possible to test if a string is less than or equal to another faster than the combination of both tests. Thibaut