Re: string-match bug?

Re: string-match bug?

[Colin S. Miller]

Andreas Roehler wrote:
> Hi,
> 
> is this a bug?
> 
> (string-match "" "foo") => 0
> 

Andreas,
that is checking if the empty string can be found somewhere in the string "foo",
which always matches at offset 0.

If you want to check if "foo" IS the empty string then do
(string-match "^$" "foo")

HTH,
Colin S. Miller

-- 
Replace the obvious in my email address with the first three letters of the hostname to reply.

Re: string-match bug?

[Colin S. Miller]

Colin S. Miller wrote:
> 
> If you want to check if "foo" IS the empty string then do
> (string-match "^$" "foo")
> 
Or, of course, use (equal "" "foo").
Don't use (eq ...), it checks if the string-object
is the same, not that they have the same value.


-- 
Replace the obvious in my email address with the first three letters of the hostname to reply.

Re: string-match bug?

[Andreas Röhler]

Colin S. Miller wrote:
> Colin S. Miller wrote:
>>
>> If you want to check if "foo" IS the empty string then do
>> (string-match "^$" "foo")
>>
> Or, of course, use (equal "" "foo").
> Don't use (eq ...), it checks if the string-object
> is the same, not that they have the same value.
> 
> 

Hi,

thanks for your answer. Let me pose the question again:

string-match asks, if a regexp is contained by string.

(equal "" "foo") reads a quite different question for me, as (string-match "^$" "foo") does.

Why should questioned string respond here it contains an empty string at position 0?
Makes no sense for me.

Andreas

Re: string-match bug?

[Matthew Dempsky]

On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:
> Why should questioned string respond here it contains an empty string at position 0?
> Makes no sense for me.

Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
This is because the first 5 characters starting at position 3 are
"xyzzy", the same as the first string parameter.  The significance of
5 here is the length of "xyzzy".

Similarly, (string-match "" "foo") returns 0.  This is because the
first 0 characters starting at position are "", the same as the first
string parameter.

Re: string-match bug?

[Andreas Röhler]

Matthew Dempsky wrote:
> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
>> Why should questioned string respond here it contains an empty string at position 0?
>> Makes no sense for me.
> 
> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
> This is because the first 5 characters starting at position 3 are
> "xyzzy", the same as the first string parameter.  The significance of
> 5 here is the length of "xyzzy".
> 

Well, string-match should tell first point of occurrence if any.
If we have none, as with slightly changed example

(string-match "xyzzy" "foox-a-yzzybar")
it duly returns "nil"  - and not "0" saying falsly "first point of non-occurence"


(string-match "" "fooxyzzybar") asks, if there is an empty string in string.
If yes, report the starting point of the empty string.

Does string start with an empty string? IMHO not.

Thanks all, interesting matter...

Andreas


> Similarly, (string-match "" "foo") returns 0.  This is because the
> first 0 characters starting at position are "", the same as the first
> string parameter.
> 

Re: string-match bug?

[Juanma Barranquero]

On Tue, Dec 8, 2009 at 11:42, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:

> Well, string-match should tell first point of occurrence if any.

This is exactly what it does.

> If we have none, as with slightly changed example
>
> (string-match "xyzzy" "foox-a-yzzybar")
> it duly returns "nil"  - and not "0" saying falsly "first point of non-occurence"

It returns nil, i.e.: there's no point in the target string at which
the regexp matches.

> (string-match "" "fooxyzzybar") asks, if there is an empty string in string.
> If yes, report the starting point of the empty string.
>
> Does string start with an empty string? IMHO not.

It returns 0, i.e.: this is the point at which the target string
matches ("" will match at the beginning of every string).

It's entirely consistent. You want string-match to answer different
questions in your first and second examples.

    Juanma

Re: string-match bug?

[Peter Münster]

On Tue, Dec 08 2009, Andreas Röhler wrote:

> (string-match "" "fooxyzzybar") asks, if there is an empty string in string.
> If yes, report the starting point of the empty string.
> 
> Does string start with an empty string? IMHO not.

Hello Andreas,

IMHO yes. Because the concatenation "" + "f" + "" + "o" + "" + "o" + ""
is the same as "foo".

You are looking for this regexp:  (string-match "^$" "foo")
Here you get nil as expected.

Cheers, Peter

-- 
Contact information: http://pmrb.free.fr/contact/

Re: string-match bug?

[Stefan Monnier]

> You are looking for this regexp:  (string-match "^$" "foo")

Of course (string-match "^$" "hello\n\nthere") -> 6


        Stefan "Don't confuse ^, $ and \`, \'"

Re: string-match bug?

[David Kastrup]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Matthew Dempsky wrote:
>> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
>> <andreas.roehler@easy-emacs.de> wrote:
>>> Why should questioned string respond here it contains an empty string at position 0?
>>> Makes no sense for me.
>> 
>> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
>> This is because the first 5 characters starting at position 3 are
>> "xyzzy", the same as the first string parameter.  The significance of
>> 5 here is the length of "xyzzy".
>> 
>
> Well, string-match should tell first point of occurrence if any.
> If we have none, as with slightly changed example
>
> (string-match "xyzzy" "foox-a-yzzybar")
> it duly returns "nil"  - and not "0" saying falsly "first point of non-occurence"
>
>
> (string-match "" "fooxyzzybar") asks, if there is an empty string in string.
> If yes, report the starting point of the empty string.
>
> Does string start with an empty string? IMHO not.

(concat "" "fooxyzzybar") -> "fooxyzzybar", so obviously the empty
string starts of the resulting string "fooxyzzybar".

-- 
David Kastrup

Re: string-match bug?

[Barry Margolin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
 Matthew Dempsky <matthew@dempsky.org> wrote:

> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
> > Why should questioned string respond here it contains an empty string at 
> > position 0?
> > Makes no sense for me.
> 
> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
> This is because the first 5 characters starting at position 3 are
> "xyzzy", the same as the first string parameter.  The significance of
> 5 here is the length of "xyzzy".
> 
> Similarly, (string-match "" "foo") returns 0.  This is because the
> first 0 characters starting at position are "", the same as the first
> string parameter.

Here's another example of a limit case:

(string-match "a*" "b") returns 0, because a* matches zero or more a's, 
and there are zero a's at position 0.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: string-match bug?

[Andreas Röhler]

Barry Margolin wrote:
> In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
>  Matthew Dempsky <matthew@dempsky.org> wrote:
> 
>> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
>> <andreas.roehler@easy-emacs.de> wrote:
>>> Why should questioned string respond here it contains an empty string at 
>>> position 0?
>>> Makes no sense for me.
>> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
>> This is because the first 5 characters starting at position 3 are
>> "xyzzy", the same as the first string parameter.  The significance of
>> 5 here is the length of "xyzzy".
>>
>> Similarly, (string-match "" "foo") returns 0.  This is because the
>> first 0 characters starting at position are "", the same as the first
>> string parameter.
> 
> Here's another example of a limit case:
> 
> (string-match "a*" "b") returns 0, because a* matches zero or more a's, 
> and there are zero a's at position 0.
> 

Hmm, interesting

IMHO that differs:

(string-match "a*" "b") asks for a non-occurrence too. So "0" of first position is plausible.

If asked for non-occurrence of empty, no problem:

The meaning of "" reverted, ie asked for the first occurence of any non-empty string, "0" would be ok also.

Still pretending: the empty string can't match any non-empty string, at no position...

Thanks all

Andreas

Re: string-match bug?

[Peter Dyballa]

Am 08.12.2009 um 11:50 schrieb Andreas Röhler:

> Barry Margolin wrote:
>> In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
>> Matthew Dempsky matthew dempsky wrote:
>>
>> Here's another example of a limit case:
>>
>> (string-match "a*" "b") returns 0, because a* matches zero or more  
>> a's,
>> and there are zero a's at position 0.
>>
>
> Hmm, interesting
>
> IMHO that differs:
>
> (string-match "a*" "b") asks for a non-occurrence too. So "0" of  
> first position is plausible.


Aren't the regular expressions "" and "a*" equivalent in that respect  
that they both also match the empty string?

--
Mit friedvollen Grüßen

   Pete

Sending unsolicited commercial eMail to this account incurs a fee of €  
500 per message and acknowledges the legality of this contract.

Re: string-match bug?

[Andreas Röhler]

Peter Dyballa wrote:
> 
> Am 08.12.2009 um 11:50 schrieb Andreas Röhler:
> 
>> Barry Margolin wrote:
>>> In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
>>> Matthew Dempsky matthew dempsky wrote:
>>>
>>> Here's another example of a limit case:
>>>
>>> (string-match "a*" "b") returns 0, because a* matches zero or more a's,
>>> and there are zero a's at position 0.
>>>
>>
>> Hmm, interesting
>>
>> IMHO that differs:
>>
>> (string-match "a*" "b") asks for a non-occurrence too. So "0" of first
>> position is plausible.
> 
> 
> Aren't the regular expressions "" and "a*" equivalent in that respect
> that they both also match the empty string?
> 

...

Ah, see some point now. If I take the "a", nothing is left...

OTOH if (string-match "a*" "b") returns NIL, will that be less plausible?

Not sure... However, see current behavior conforms to POSIX

http://www.opengroup.org/onlinepubs/009695399/

So I'll simply keep it in mind, hopefully...


Thanks all again

Andreas

Re: string-match bug?

[Barry Margolin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

In article <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>,
 Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> Barry Margolin wrote:
> > In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
> >  Matthew Dempsky <matthew@dempsky.org> wrote:
> > 
> >> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
> >> <andreas.roehler@easy-emacs.de> wrote:
> >>> Why should questioned string respond here it contains an empty string at 
> >>> position 0?
> >>> Makes no sense for me.
> >> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
> >> This is because the first 5 characters starting at position 3 are
> >> "xyzzy", the same as the first string parameter.  The significance of
> >> 5 here is the length of "xyzzy".
> >>
> >> Similarly, (string-match "" "foo") returns 0.  This is because the
> >> first 0 characters starting at position are "", the same as the first
> >> string parameter.
> > 
> > Here's another example of a limit case:
> > 
> > (string-match "a*" "b") returns 0, because a* matches zero or more a's, 
> > and there are zero a's at position 0.
> > 
> 
> Hmm, interesting
> 
> IMHO that differs:
> 
> (string-match "a*" "b") asks for a non-occurrence too. So "0" of first 
> position is plausible.

What's the difference between a non-occurrence and a zero-length 
occurrence?

The nice thing about regular expressions is that the following syllogism 
holds:

If 
(string-match (concat regex1 regex2) (concat str1 str2))
then
(and (string-match regex1 str1) (string-match regex2 str2))

You need the empty regex case to work for the limiting case of this.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: string-match bug?

[Pascal J. Bourguignon]

Barry Margolin <barmar@alum.mit.edu> writes:

> In article <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>,
>  Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>
>> Barry Margolin wrote:
>> > In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
>> >  Matthew Dempsky <matthew@dempsky.org> wrote:
>> > 
>> >> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
>> >> <andreas.roehler@easy-emacs.de> wrote:
>> >>> Why should questioned string respond here it contains an empty string at 
>> >>> position 0?
>> >>> Makes no sense for me.
>> >> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
>> >> This is because the first 5 characters starting at position 3 are
>> >> "xyzzy", the same as the first string parameter.  The significance of
>> >> 5 here is the length of "xyzzy".
>> >>
>> >> Similarly, (string-match "" "foo") returns 0.  This is because the
>> >> first 0 characters starting at position are "", the same as the first
>> >> string parameter.
>> > 
>> > Here's another example of a limit case:
>> > 
>> > (string-match "a*" "b") returns 0, because a* matches zero or more a's, 
>> > and there are zero a's at position 0.
>> > 
>> 
>> Hmm, interesting
>> 
>> IMHO that differs:
>> 
>> (string-match "a*" "b") asks for a non-occurrence too. So "0" of first 
>> position is plausible.
>
> What's the difference between a non-occurrence and a zero-length 
> occurrence?
>
> The nice thing about regular expressions is that the following syllogism 
> holds:
>
> If 
> (string-match (concat regex1 regex2) (concat str1 str2))
> then
> (and (string-match regex1 str1) (string-match regex2 str2))
>
> You need the empty regex case to work for the limiting case of this.


(defun imply (a b) (or (not a)  b))

(let ((regex1 "a")
      (regex2 "b")
      (str1 "ab")
      (str2 "x"))

  (imply (string-match (concat regex1 regex2) (concat str1 str2))
         (and  (string-match  regex1 str1) (string-match  regex2 str2))))

--> nil


Perhaps you mean:

  (imply (and  (string-match  regex1 str1) (string-match  regex2 str2))
         (string-match (concat regex1 regex2) (concat str1 str2)))


-- 
__Pascal Bourguignon__

Re: string-match bug?

[Stefan Monnier]

> Perhaps you mean:

>   (imply (and  (string-match  regex1 str1) (string-match  regex2 str2))
>          (string-match (concat regex1 regex2) (concat str1 str2)))

Of course, even that one isn't 100% true, if you consider the case where
regex1 ends with $, for example.


        Stefn

Re: string-match bug?

[Matthew Dempsky]

On Tue, Dec 8, 2009 at 12:48 PM, Barry Margolin <barmar@alum.mit.edu> wrote:
> If
> (string-match (concat regex1 regex2) (concat str1 str2))
> then
> (and (string-match regex1 str1) (string-match regex2 str2))

Not quite: STRING-MATCH searches for a substring that matches a
specified regexp; it doesn't return whether the whole string matches
the regexp.

Re: string-match bug?

[Andreas Röhler]

Matthew Dempsky wrote:
> On Tue, Dec 8, 2009 at 12:48 PM, Barry Margolin <barmar@alum.mit.edu> wrote:
>> If
>> (string-match (concat regex1 regex2) (concat str1 str2))
>> then
>> (and (string-match regex1 str1) (string-match regex2 str2))
> 
> Not quite: STRING-MATCH searches for a substring that matches a
> specified regexp; it doesn't return whether the whole string matches
> the regexp.
> 
> 
> 

As said, present behavior is POSIX and I don't question that for now.
Nonetheless, returning NIL at the second question looks like a more useful result -
because taking incertitude.

(string-match "a" "a") => 0
(string-match "" "a") => 0
(string-match "" "") => 0

Re: string-match bug?

[Juanma Barranquero]

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.

    Juanma

Re: string-match bug?

[Andreas Röhler]

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.
Result is logically not plausible for me - even if I'm well able to live with... :)



> 
>     Juanma
> 

Re: string-match bug?

[Matthew Dempsky]

On Wed, Dec 9, 2009 at 9:33 AM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:
> But simply by convention, isn't it?

No.  It's because it's consistent and makes sense.  That's why every
sane programming language does it this way:

C: s = "foo", strstr(s, "") evaluates to s
C++: string("foo").find("") evaluates to 0
Python: 'foo'.find('') evaluates to 0
Ruby: 'foo'.index('') evaluates to 0
Perl: index("foo", "") evaluates to 0

Re: string-match bug?

[tomas]

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

On Wed, Dec 09, 2009 at 10:07:56AM -0800, Matthew Dempsky wrote:
> On Wed, Dec 9, 2009 at 9:33 AM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
> > But simply by convention, isn't it?
> 
> No.  It's because it's consistent and makes sense.  That's why every
> sane programming language does it this way:

Ah, nice: our postings crossed :)

But I think it_is_ a convention -- just the one which makes most sense.

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

iD8DBQFLH+jEBcgs9XrR2kYRApjFAJ9llWu4/ms+EymRkIKO50SmfF8cVQCeIVIH
6RWS0RoHmC9aKYnNxYjJT1s=
=u8dn
-----END PGP SIGNATURE-----

Re: string-match bug?

[Andreas Röhler]

Matthew Dempsky wrote:
> On Wed, Dec 9, 2009 at 9:33 AM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
>> But simply by convention, isn't it?
> 
> No.  It's because it's consistent and makes sense.  That's why every
> sane programming language does it this way:
> 
> C: s = "foo", strstr(s, "") evaluates to s


CMIIW but does this example above not mean, it returns
the string? So far quite different from the rest?

Thanks all BTW, very instructive for me.

Andreas

> C++: string("foo").find("") evaluates to 0
> Python: 'foo'.find('') evaluates to 0
> Ruby: 'foo'.index('') evaluates to 0
> Perl: index("foo", "") evaluates to 0
> 

Re: string-match bug?

[Matthew Dempsky]

On Wed, Dec 9, 2009 at 10:59 AM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:
> CMIIW but does this example above not mean, it returns
> the string?

strstr(s, t) searches s for the first occurrence of t in s, and then
returns a pointer to that offset if it finds one, and returns NULL
otherwise.

> So far quite different from the rest?

Semantically, the meaning is the same: it found an empty string at the
start of the haystack string.

Re: string-match bug?

[Barry Margolin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

In article <mailman.12615.1260385212.2239.help-gnu-emacs@gnu.org>,
 Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> Matthew Dempsky wrote:
> > On Wed, Dec 9, 2009 at 9:33 AM, Andreas Röhler
> > <andreas.roehler@easy-emacs.de> wrote:
> >> But simply by convention, isn't it?
> > 
> > No.  It's because it's consistent and makes sense.  That's why every
> > sane programming language does it this way:
> > 
> > C: s = "foo", strstr(s, "") evaluates to s
> 
> 
> CMIIW but does this example above not mean, it returns
> the string? So far quite different from the rest?

Not really.  It's just that strstr() reports a successful match by 
returning a pointer to the first character of the match; the other 
functions return the position.  They're isomorphic.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: string-match bug?

[tomas]

-----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-----

Re: string-match bug?

[Kevin Rodgers]

Andreas Röhler wrote:
> 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.

Actually, it has an infinite number of empty strings at position 0
-- and at every position.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: string-match bug?

[Stefan Monnier]

> Actually, it has an infinite number of empty strings at position 0
> -- and at every position.

Good, thank you.  I never took the time to count them, so I always
wondered whether there really were enough of them to count as "an
infinite number".  I'm glad it's settled.


        Stefan

Re: string-match bug?

[tomas]

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

On Thu, Dec 10, 2009 at 12:34:45AM -0500, Stefan Monnier wrote:
> > Actually, it has an infinite number of empty strings at position 0
> > -- and at every position.
> 
> Good, thank you.  I never took the time to count them, so I always
> wondered whether there really were enough of them to count as "an
> infinite number".  I'm glad it's settled.

Far from it! the more interesting question: countable? /me tries in vain
to hide from Cantor's ghost)

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

iD8DBQFLIMbiBcgs9XrR2kYRAuaeAJ4iKq7fXh0BbIy9aM4QEpX6YU+KiQCeJkT5
OA/bRavoFc3GAdTG0wnQCR4=
=yX/Z
-----END PGP SIGNATURE-----

Re: string-match bug?

[Andreas Politz]

tomas@tuxteam.de writes:

> On Thu, Dec 10, 2009 at 12:34:45AM -0500, Stefan Monnier wrote:
>> > Actually, it has an infinite number of empty strings at position 0
>> > -- and at every position.
>> 
>> Good, thank you.  I never took the time to count them, so I always
>> wondered whether there really were enough of them to count as "an
>> infinite number".  I'm glad it's settled.
>
> Far from it! the more interesting question: countable? /me tries in vain
> to hide from Cantor's ghost)
>
> Regards
> -- tomás

Counting them is easy with the greedy operator.

(and (string-match "\\(\\)*" "")
     (match-end 0))

This proofs, empty strings don't exist.

-ap

Re: string-match bug?

[Kevin Rodgers]

Andreas Politz wrote:
> tomas@tuxteam.de writes:
> 
>> On Thu, Dec 10, 2009 at 12:34:45AM -0500, Stefan Monnier wrote:
>>>> Actually, it has an infinite number of empty strings at position 0
>>>> -- and at every position.
>>> Good, thank you.  I never took the time to count them, so I always
>>> wondered whether there really were enough of them to count as "an
>>> infinite number".  I'm glad it's settled.
>> Far from it! the more interesting question: countable? /me tries in vain
>> to hide from Cantor's ghost)
>>
>> Regards
>> -- tomás
> 
> Counting them is easy with the greedy operator.
> 
> (and (string-match "\\(\\)*" "")
>      (match-end 0))
> 
> This proofs, empty strings don't exist.

It proves that (a) 0 or more empty strings match the empty string and
(b) the match ends at the end of the empty string (which having length
0, has start position equal to end position equal to 0 i.e. the returned
value).

Here's how to count the number of of times the empty string matches any
string S at position N:

(let ((match-count 0))
   (while (string-match "\\(\\)" S N)
     (setq match-count (1+ match-count)
	  N (match-end 0)))
   match-count)

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: string-match bug?

[David Kastrup]

Andreas Politz <politza@fh-trier.de> writes:

> tomas@tuxteam.de writes:
>
>> On Thu, Dec 10, 2009 at 12:34:45AM -0500, Stefan Monnier wrote:
>>> > Actually, it has an infinite number of empty strings at position 0
>>> > -- and at every position.
>>> 
>>> Good, thank you.  I never took the time to count them, so I always
>>> wondered whether there really were enough of them to count as "an
>>> infinite number".  I'm glad it's settled.
>>
>> Far from it! the more interesting question: countable? /me tries in vain
>> to hide from Cantor's ghost)
>>
>> Regards
>
> Counting them is easy with the greedy operator.
>
> (and (string-match "\\(\\)*" "a")
>      (match-end 0))
>
> This proofs, empty strings don't exist.

Huh?  That does not count them.  It gives their total length at the
first match, but the total length will be zero regardless of the number
of matches.

-- 
David Kastrup

Re: string-match bug?

[Frank Fredstone]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Aren't
>
> (string-match "" "a")
>
> and
>
> (string-match "" "")
>
> different cases in some perspective?

You can think of it like this:

If you line up 3 boxes left to right, where among them are there no
boxes? There are no boxes before the first, between the first and the
second, between the second and the third and after the last. The first
place (position left to right) where there are no boxes, is before the
first (position 0).

Re: string-match bug?

[Andreas Röhler]

Frank Fredstone wrote:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> 
>> Aren't
>>
>> (string-match "" "a")
>>
>> and
>>
>> (string-match "" "")
>>
>> different cases in some perspective?
> 
> You can think of it like this:
> 
> If you line up 3 boxes left to right, where among them are there no
> boxes? There are no boxes before the first, between the first and the
> second, between the second and the third and after the last. The first
> place (position left to right) where there are no boxes, is before the
> first (position 0).
> 
> 

well, isn't the first 0?
before the first would be -1 then?

Andreas

Re: string-match bug?

[Juanma Barranquero]

On Thu, Dec 10, 2009 at 20:25, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:

> well, isn't the first 0?
> before the first would be -1 then?

There's no position -1 on the string. The first place where you do
find a null string is at 0.

    Juanma

Re: string-match bug?

[Frank Fredstone]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Frank Fredstone wrote:
>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>> 
>>> Aren't
>>>
>>> (string-match "" "a")
>>>
>>> and
>>>
>>> (string-match "" "")
>>>
>>> different cases in some perspective?
>> 
>> You can think of it like this:
>> 
>> If you line up 3 boxes left to right, where among them are there no
>> boxes? There are no boxes before the first, between the first and the
>> second, between the second and the third and after the last. The first
>> place (position left to right) where there are no boxes, is before the
>> first (position 0).
>> 
>> 
>
> well, isn't the first 0?
> before the first would be -1 then?

Before the first, would be -1, if there were a box there. But, we're
talking about where no boxes are. There is no box before the first, at
position 0.

Re: string-match bug?

[Stefan Monnier]

> But simply by convention, isn't it?

No: it's the most consistent behavior, i.e. a natural consequence of the
usual rules obeyed by regular expressions.

> Aren't
>     (string-match "" "a")
> and
>     (string-match "" "")
> different cases in some perspective?

How 'bout

     (string-match "b" "ba")
vs
     (string-match "b" "b")


-- Stefan

Re: string-match bug?

[Andreas Röhler]

Stefan Monnier wrote:
>> But simply by convention, isn't it?
> 
> No: it's the most consistent behavior, i.e. a natural consequence of the
> usual rules obeyed by regular expressions.
> 
>> Aren't
>>     (string-match "" "a")
>> and
>>     (string-match "" "")
>> different cases in some perspective?
> 
> How 'bout
> 
>      (string-match "b" "ba")
> vs
>      (string-match "b" "b")
> 
> 
> -- Stefan
> 

OK, see the point. As said, I can perfectly live with the "0".

OTOH still remains the empty string a special case of match, which could be signaled
in it's quality difference.

BTW, lacking any practical case, where a change would pay, I don't suggest one...


Andreas

Re: string-match bug?

[David Kastrup]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Barry Margolin wrote:
>> In article <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>,
>>  Matthew Dempsky <matthew@dempsky.org> wrote:
>> 
>>> On Mon, Dec 7, 2009 at 12:37 PM, Andreas Röhler
>>> <andreas.roehler@easy-emacs.de> wrote:
>>>> Why should questioned string respond here it contains an empty string at 
>>>> position 0?
>>>> Makes no sense for me.
>>> Here's an analogy: (string-match "xyzzy" "fooxyzzybar") returns 3.
>>> This is because the first 5 characters starting at position 3 are
>>> "xyzzy", the same as the first string parameter.  The significance of
>>> 5 here is the length of "xyzzy".
>>>
>>> Similarly, (string-match "" "foo") returns 0.  This is because the
>>> first 0 characters starting at position are "", the same as the first
>>> string parameter.
>> 
>> Here's another example of a limit case:
>> 
>> (string-match "a*" "b") returns 0, because a* matches zero or more a's, 
>> and there are zero a's at position 0.
>
> Hmm, interesting
>
> IMHO that differs:
>
> Still pretending: the empty string can't match any non-empty string,
> at no position...

Since (concat "" "foo")->"foo", obviously "" is contained in "foo" at
position 0.  The same argument holds for any other position.  Including
after the last character.

-- 
David Kastrup

string-match bug?

[Andreas Roehler]

Hi,

is this a bug?

(string-match "" "foo") => 0

Andreas

GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2009-07-25
BTW XEmacs behaves likewise.

Re: string-match bug?

[Pierre Lorenzon]

From: Andreas Roehler <andreas.roehler@online.de>
Subject: string-match bug?
Date: Mon, 07 Dec 2009 15:55:08 +0100

> Hi,
> 
> is this a bug?

  You might verify if it is posix complient or not. If not, it
  would sound to me like a bug ...

  Pierre



> 
> (string-match "" "foo") => 0
> 
> Andreas
> 
> GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2009-07-25
> BTW XEmacs behaves likewise.
> 
>