From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Andryshak Newsgroups: gmane.emacs.devel Subject: Re: string> missing? Date: Wed, 03 Jun 2015 15:34:14 -0400 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 X-Trace: ger.gmane.org 1433360133 7671 80.91.229.3 (3 Jun 2015 19:35:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jun 2015 19:35:33 +0000 (UTC) Cc: nicolas@petton.fr, emacs-devel@gnu.org, tsdh@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 03 21:35:33 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 1Z0EQj-0003CP-Hx for ged-emacs-devel@m.gmane.org; Wed, 03 Jun 2015 21:34:25 +0200 Original-Received: from localhost ([::1]:37398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0EQi-0003eM-U1 for ged-emacs-devel@m.gmane.org; Wed, 03 Jun 2015 15:34:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0EQe-0003eA-V9 for emacs-devel@gnu.org; Wed, 03 Jun 2015 15:34:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0EQa-0004aW-SG for emacs-devel@gnu.org; Wed, 03 Jun 2015 15:34:20 -0400 Original-Received: from mail-vn0-x22d.google.com ([2607:f8b0:400c:c0f::22d]:44225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0EQa-0004aM-OO; Wed, 03 Jun 2015 15:34:16 -0400 Original-Received: by vnbg129 with SMTP id g129so2498123vnb.11; Wed, 03 Jun 2015 12:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; bh=JpEou5BL1zpHn1eZKWhMP79Lgl8d6pYM2rflHigYnVE=; b=Tl+fBDRe1s+YjE7MbfPZtQistJdLmoDR2gEoOJReFFrl63aVTHAl2vExxdtdEQqF3F mrDGFBt/p4/L64iP673E7jKaD4LOP2fjO+s+8FvsoJpwuJsbqfiBJrBKMjBSS+f/xKBX UZALcEePXw7Q15HUzC6r9h5XcQuWFm9jiOcdrP6oBYObu9XBYFNEyHefTIm/VOt4U5Ni scB7WBWQetC1TGg7uN6u7d9WYXFY3kPIObe6weDEYmNehTr8w0TkhNAZ21rfHqjiE5gW 7EFSuEVcm+rNyAjv5ryK0RpFdWo0juE1CfVUFmyaB46UY8x5rZTHyoWqbSIUlv1zRYC2 awAQ== X-Received: by 10.52.11.5 with SMTP id m5mr50914351vdb.53.1433360056229; Wed, 03 Jun 2015 12:34:16 -0700 (PDT) Original-Received: from NAND-LT ([47.19.134.82]) by mx.google.com with ESMTPSA id h14sm1909315vdj.0.2015.06.03.12.34.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 12:34:15 -0700 (PDT) In-reply-to: <83mw0gr4eh.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c0f::22d 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:186998 Archived-At: >> What good reasons are there specifically to keep the '>' function? >> What does '(> A B)' do that '(< B A)' doesn't? > > If you want to argue for removal of one of them, feel free. Perhaps my comparison was not explicit enough: it was intended to make you think about why both < and > exist when one is clearly "enough", and then apply those same reasons to the issue at hand. So, why do both exist? Readability, maybe. Sometimes it's nicer or it makes more sense to use "greater than" over "less than" or vice versa. > But that doesn't reflect in any way on the issue at hand. Once again, > there's no requirement to be "consistent" in this sense. Of course consistency is not a /requirement/, I never claimed it was. But I think we would agree that it's usually a good goal to strive towards because inconsistent leads to confusing and a bad user experience. 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>. - Nick