help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: string-match bug?


From: tomas
Subject: Re: string-match bug?
Date: Wed, 9 Dec 2009 19:11:57 +0100
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Dec 09, 2009 at 06:33:05PM +0100, Andreas Röhler wrote:
> Juanma Barranquero wrote:
> > On Wed, Dec 9, 2009 at 09:05, Andreas Röhler
> > <andreas.roehler@easy-emacs.de> wrote:
> > 
> >> Nonetheless, returning NIL at the second question looks like a more useful 
> >> result -
> > 
> > Why?
> > 
> >> because taking incertitude.
> > 
> > Which incertitude? Matching the empty regexp against any string is
> > always going to match.
> 
> But simply by convention, isn't it?
> 
> Aren't
> 
> (string-match "" "a")
> 
> and
> 
> (string-match "" "")
> 
> different cases in some perspective?
> 
> The return value is censured being a position.
> Second case is plausible, there is an empty string at pos 0.
> 
> 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" => "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) => "wz"
(substring "yowza!" 2 2) => ""

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 live 
> 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 == START, but
what for?).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLH+htBcgs9XrR2kYRAjuSAJ9gxEnrgiR8Rrl2GO9uYb7t6tbnkwCfc2MC
7QJcRIjEt9yTpSxPRdU+BNs=
=FZ4V
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]