From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: string> missing? Date: Thu, 04 Jun 2015 08:43:20 +0200 Message-ID: <87vbf4dldj.fsf@gnu.org> 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> <83d21cqj9y.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1433400264 11661 80.91.229.3 (4 Jun 2015 06:44:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Jun 2015 06:44:24 +0000 (UTC) Cc: nicolas@petton.fr, nandryshak@gmail.com, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 04 08:44:13 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 1Z0OsR-0006tF-5F for ged-emacs-devel@m.gmane.org; Thu, 04 Jun 2015 08:43:43 +0200 Original-Received: from localhost ([::1]:40376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0OsP-0006om-VE for ged-emacs-devel@m.gmane.org; Thu, 04 Jun 2015 02:43:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0OsC-0006oW-J8 for emacs-devel@gnu.org; Thu, 04 Jun 2015 02:43:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0Os9-0001GW-7y for emacs-devel@gnu.org; Thu, 04 Jun 2015 02:43:28 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:46710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0Os8-0001Fe-WC for emacs-devel@gnu.org; Thu, 04 Jun 2015 02:43:25 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E206A2074B for ; Thu, 4 Jun 2015 02:43:23 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 04 Jun 2015 02:43:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=41cZNjzz65r+dxOcFiZqK+ARwLs=; b=BGehn U0Oy59DpS+SBiTjwBd2W0HVRl0fdaAwBicRRNkuUxz12lXN6Nq5ZDIefAJsMXM3o p1nVQJ2fTSP2/mRAdpf2e0U2htoP2CwquYKkvtvvi+tIjvXb/tm6paG5RjkvI0Iy U+R+HUoiw8aIGty7+oTENQoc7gBJjvApR4RKxM= X-Sasl-enc: 454sF7nwFq+iQOSsFU/52lwMw9Cs9fGl5Nr28N+OVIoX 1433400203 Original-Received: from thinkpad-t440p (unknown [2.162.125.227]) by mail.messagingengine.com (Postfix) with ESMTPA id 75944C0001B; Thu, 4 Jun 2015 02:43:22 -0400 (EDT) Mail-Followup-To: Eli Zaretskii , Stefan Monnier , nandryshak@gmail.com, nicolas@petton.fr, emacs-devel@gnu.org In-Reply-To: <83d21cqj9y.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Jun 2015 05:50:17 +0300") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.28 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:187012 Archived-At: Eli Zaretskii writes: >> Emacs is inconsistent. That's part of its inheritance. >> If someone wants to add string>, I'm perfectly OK with it. > > Why not _remove_ string< and use compare-strings for both jobs? Oh yes, please. Everybody wants to use a function of 6-7 arguments! ;-) Fun aside: aside from the reason of symmertry/consistency, I can see at least two practical advantages of having `string>'. Whenever it should be used as predicate of a higher-order function, (sort coll #'string>) is more concise than (sort coll (lambda (a b) (string< b a))) and it is also better to edebug because you are usually not interested in edebugging the lambda. (What can possibly go wrong there?!?) However, this is true for any other simple predicate aside from number or string comparison. So I'd suggest to have a `complement' function which simply returns a function negating the value of some predicate, e.g., (defun complement (fn) "Returns a function calling FN and returning FN's negated value." (lambda (&rest args) (not (apply fn args)))) Then you can do (sort coll (complement #'string<)) which looks like a good compromise wrt conciseness and edebuggability. Of course, (complement #'string<) is string>= which will work fine for `sort' but probably not for other higer-order functions. Grepping the emacs source code, there are indeed at least three occurrences of (nreverse (sort coll predicate)) which could make use of that. And I can also find occurrences of (lambda (a b) (string< b a)). However, when the number of definitions is what makes a function which is currently not provided by Elisp important, than it looks to me that there should be a function for (lambda (a b) (string< (car a) (car b))) For that, `rgrep' delivers 40 matches in the elisp repositories I have on my disk, and I only searched for "(lambda (. .) (string< (car .) (car .)))" so it has to occur on one line with the exact spacing and 1-char wide arguments. So that suggests we want to have a `car-string-less-than-car' (or indeed want to have the numerical comparison functions work for strings, too, as Stefan suggested because there's already `car-less-than-car'). Bye, Tassilo