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: Thu, 4 Jun 2015 07:30:08 +0200 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> Reply-To: thibaut.verron@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1433395852 12948 80.91.229.3 (4 Jun 2015 05:30:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Jun 2015 05:30:52 +0000 (UTC) Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 04 07:30:42 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 1Z0Njg-0002T7-SH for ged-emacs-devel@m.gmane.org; Thu, 04 Jun 2015 07:30:37 +0200 Original-Received: from localhost ([::1]:40248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0Njg-0000ts-24 for ged-emacs-devel@m.gmane.org; Thu, 04 Jun 2015 01:30:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0Njc-0000tb-AB for emacs-devel@gnu.org; Thu, 04 Jun 2015 01:30:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0Njb-0007ZS-6D for emacs-devel@gnu.org; Thu, 04 Jun 2015 01:30:32 -0400 Original-Received: from mail-wg0-x235.google.com ([2a00:1450:400c:c00::235]:32818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0Nja-0007Yl-Vi for emacs-devel@gnu.org; Thu, 04 Jun 2015 01:30:31 -0400 Original-Received: by wgez8 with SMTP id z8so24724471wge.0 for ; Wed, 03 Jun 2015 22:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QIYSWFndoKiZbAET98TMxBwlwn/2LjnvbJwvLJf/v/s=; b=ZEzXxTVLmZFxIAtnzdW/NuK9ov0BV+DaeAOvwzRIDSDWM38hVXD+EXKQul1KQ40281 ZLCYRr9bb7ppVnQJ38ntTFwd0iTrhKYUClljg7fmdeplxWicgcGLst0+QXmu8OIgn+TY SixrOTggyWGujHLAdvQU1GfROeiVRh0Wijfx4Gbt8homExoLMKRlKqVcEjQC5MVsHJl1 Yd7YEpq97t02IKFABlYYLX3Vw2rJ2+DFljAXrSDoYd7LcPF2QoJex2NXt+l8mkSLmXeo uAR6umaMKsidUy/iiyVrTlnC1u8FBmTYHDUfgoksbvzXo71XL34JUOsmPKNqb23BV+1N TYJQ== X-Received: by 10.194.23.66 with SMTP id k2mr35563384wjf.18.1433395829262; Wed, 03 Jun 2015 22:30:29 -0700 (PDT) Original-Received: by 10.27.11.166 with HTTP; Wed, 3 Jun 2015 22:30:08 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::235 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:187011 Archived-At: 2015-06-04 0:25 GMT+02:00 Stefan Monnier : > > > testing strings for equality in emacs lisp is already tricky enough! > > Now, regardless of whether I agree with the rest of what is being said > in this thread, this part really puzzles me. I do think there are some > tricky/subtle issues in string equality testing in Emacs, but these are > sufficiently subtle that most people will never know about them. > > So, what are you referring to here? > Mostly to this: (setq str1 "foo") (setq str2 "foo") (setq str3 str1) (= str1 str2) ;;==> *error* (eq str1 str2) ;;==> nil (eq str1 "foo") ;;==> nil (eq str1 str3) ;;==> nil (string= str1 str2) ;;==> t The first two candidates for a newcomer to string testing don't return the expected result, because = is really number=, and eq does not test for structural equality (and is basically useless for strings, as I understand it). Now maybe tricky is a strong word, after all it is properly documented once you notice the issue. And I wouldn't be able to suggest a better way of exposing these functions. For the thread at hand, obviously if one is looking for a string> function, one knows about string=. But I can't help but imagine a developer running into both annoyances on the same day: the first one has deep roots, but the second one is trivial to fix, couldn't we spare him that? Thibaut