From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.help Subject: Re: string-match bug? Date: Wed, 9 Dec 2009 19:11:57 +0100 Message-ID: <20091209181157.GA17507@tomas> References: <4b1d1e3d$0$276$14726298@news.sunsite.dk> <4B1D6773.3000509@easy-emacs.de> <4B1F5A38.1030703@easy-emacs.de> <4B1FDF51.1010002@easy-emacs.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1260382682 7514 80.91.229.12 (9 Dec 2009 18:18:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Dec 2009 18:18:02 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Andreas =?iso-8859-1?Q?R=F6hler?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 09 19:17:56 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NIR6p-0007pw-9c for geh-help-gnu-emacs@m.gmane.org; Wed, 09 Dec 2009 19:17:55 +0100 Original-Received: from localhost ([127.0.0.1]:37815 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIR6o-00041U-Qr for geh-help-gnu-emacs@m.gmane.org; Wed, 09 Dec 2009 13:17:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIR6V-00040z-1M for help-gnu-emacs@gnu.org; Wed, 09 Dec 2009 13:17:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIR6Q-00040L-8h for help-gnu-emacs@gnu.org; Wed, 09 Dec 2009 13:17:34 -0500 Original-Received: from [199.232.76.173] (port=44262 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIR6P-00040I-UG for help-gnu-emacs@gnu.org; Wed, 09 Dec 2009 13:17:29 -0500 Original-Received: from alextrapp1.equinoxe.de ([217.22.192.104]:53066 helo=www.elogos.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIR6P-0001X3-Hf for help-gnu-emacs@gnu.org; Wed, 09 Dec 2009 13:17:29 -0500 Original-Received: by www.elogos.de (Postfix, from userid 1000) id A0C0890049; Wed, 9 Dec 2009 19:11:57 +0100 (CET) Content-Disposition: inline In-Reply-To: <4B1FDF51.1010002@easy-emacs.de> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:70531 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 09, 2009 at 06:33:05PM +0100, Andreas R=C3=B6hler wrote: > Juanma Barranquero wrote: > > On Wed, Dec 9, 2009 at 09:05, Andreas R=C3=B6hler > > wrote: > >=20 > >> Nonetheless, returning NIL at the second question looks like a more = useful result - > >=20 > > Why? > >=20 > >> because taking incertitude. > >=20 > > Which incertitude? Matching the empty regexp against any string is > > always going to match. >=20 > But simply by convention, isn't it? >=20 > Aren't >=20 > (string-match "" "a") >=20 > and >=20 > (string-match "" "") >=20 > different cases in some perspective? >=20 > The return value is censured being a position. > Second case is plausible, there is an empty string at pos 0. >=20 > First has no empty string at pos 0. Of course it has don't you see it, very little there, between the " and the a? There is another one at the end, right there between the a an the ". ;-) Humour aside -- it makes things square up better. If you consider the operation of "string concatenation", there is a "neutral element" (that is the empty string). Thus "" + "foo" =3D> "foo". So you can assume the empty string to be everywhere within a string (or to be a substring of every string at each position). Watch this: (substring "yowza!" 2 4) =3D> "wz" (substring "yowza!" 2 2) =3D> "" So, "" is a substring of the string "yowza! at position 2 (it just happens to have the length 0). > Result is logically not plausible for me - even if I'm well able to liv= e with... :) It isn't logical. It's just a convention (but the one convention which happens to make things easiest in the end). You can see a simiilar convention in maths: in set theory, the empty set is considered to be a subset of every set. Of course you might redefine all set operators (inclusion, intersection, etc.) to exclude the empty set, but you would just end up with tons of special cases for no gain. Same here (you'd need, e.g. to special-case the substring function when END =3D=3D START, = but what for?). Regards - -- tom=C3=A1s -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLH+htBcgs9XrR2kYRAjuSAJ9gxEnrgiR8Rrl2GO9uYb7t6tbnkwCfc2MC 7QJcRIjEt9yTpSxPRdU+BNs=3D =3DFZ4V -----END PGP SIGNATURE-----