unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* string-match bug?
@ 2009-12-07 14:55 Andreas Roehler
  2009-12-07 15:31 ` Pierre Lorenzon
  0 siblings, 1 reply; 41+ messages in thread
From: Andreas Roehler @ 2009-12-07 14:55 UTC (permalink / raw)
  To: help-gnu-emacs

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.




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found] <mailman.12437.1260197731.2239.help-gnu-emacs@gnu.org>
@ 2009-12-07 15:08 ` Colin S. Miller
  2009-12-07 15:25   ` Colin S. Miller
  0 siblings, 1 reply; 41+ messages in thread
From: Colin S. Miller @ 2009-12-07 15:08 UTC (permalink / raw)
  To: help-gnu-emacs

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.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-07 15:08 ` string-match bug? Colin S. Miller
@ 2009-12-07 15:25   ` Colin S. Miller
  2009-12-07 20:37     ` Andreas Röhler
  0 siblings, 1 reply; 41+ messages in thread
From: Colin S. Miller @ 2009-12-07 15:25 UTC (permalink / raw)
  To: help-gnu-emacs

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.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-07 14:55 Andreas Roehler
@ 2009-12-07 15:31 ` Pierre Lorenzon
  0 siblings, 0 replies; 41+ messages in thread
From: Pierre Lorenzon @ 2009-12-07 15:31 UTC (permalink / raw)
  To: andreas.roehler; +Cc: help-gnu-emacs

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






^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-07 15:25   ` Colin S. Miller
@ 2009-12-07 20:37     ` Andreas Röhler
  2009-12-07 21:23       ` Matthew Dempsky
       [not found]       ` <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 41+ messages in thread
From: Andreas Röhler @ 2009-12-07 20:37 UTC (permalink / raw)
  To: Colin S. Miller; +Cc: help-gnu-emacs

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







^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-07 20:37     ` Andreas Röhler
@ 2009-12-07 21:23       ` Matthew Dempsky
  2009-12-08 10:42         ` Andreas Röhler
       [not found]         ` <mailman.12517.1260268988.2239.help-gnu-emacs@gnu.org>
       [not found]       ` <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>
  1 sibling, 2 replies; 41+ messages in thread
From: Matthew Dempsky @ 2009-12-07 21:23 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs

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.




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]       ` <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>
@ 2009-12-08  3:22         ` Barry Margolin
  2009-12-08 10:50           ` Andreas Röhler
       [not found]           ` <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 41+ messages in thread
From: Barry Margolin @ 2009-12-08  3:22 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-07 21:23       ` Matthew Dempsky
@ 2009-12-08 10:42         ` Andreas Röhler
  2009-12-08 11:35           ` Juanma Barranquero
                             ` (2 more replies)
       [not found]         ` <mailman.12517.1260268988.2239.help-gnu-emacs@gnu.org>
  1 sibling, 3 replies; 41+ messages in thread
From: Andreas Röhler @ 2009-12-08 10:42 UTC (permalink / raw)
  To: Matthew Dempsky; +Cc: help-gnu-emacs

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





^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08  3:22         ` Barry Margolin
@ 2009-12-08 10:50           ` Andreas Röhler
  2009-12-08 11:31             ` Peter Dyballa
       [not found]           ` <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>
  1 sibling, 1 reply; 41+ messages in thread
From: Andreas Röhler @ 2009-12-08 10:50 UTC (permalink / raw)
  To: Barry Margolin; +Cc: help-gnu-emacs

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









^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 10:50           ` Andreas Röhler
@ 2009-12-08 11:31             ` Peter Dyballa
  2009-12-08 13:55               ` Andreas Röhler
  0 siblings, 1 reply; 41+ messages in thread
From: Peter Dyballa @ 2009-12-08 11:31 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs, Barry Margolin


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.





^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 10:42         ` Andreas Röhler
@ 2009-12-08 11:35           ` Juanma Barranquero
  2009-12-08 11:50           ` Peter Münster
       [not found]           ` <mailman.12522.1260273034.2239.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 41+ messages in thread
From: Juanma Barranquero @ 2009-12-08 11:35 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 10:42         ` Andreas Röhler
  2009-12-08 11:35           ` Juanma Barranquero
@ 2009-12-08 11:50           ` Peter Münster
       [not found]           ` <mailman.12522.1260273034.2239.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 41+ messages in thread
From: Peter Münster @ 2009-12-08 11:50 UTC (permalink / raw)
  To: Emacs Users

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/






^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 11:31             ` Peter Dyballa
@ 2009-12-08 13:55               ` Andreas Röhler
  0 siblings, 0 replies; 41+ messages in thread
From: Andreas Röhler @ 2009-12-08 13:55 UTC (permalink / raw)
  To: help-gnu-emacs

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









^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]           ` <mailman.12522.1260273034.2239.help-gnu-emacs@gnu.org>
@ 2009-12-08 15:56             ` Stefan Monnier
  0 siblings, 0 replies; 41+ messages in thread
From: Stefan Monnier @ 2009-12-08 15:56 UTC (permalink / raw)
  To: help-gnu-emacs

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

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


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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]           ` <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>
@ 2009-12-08 20:48             ` Barry Margolin
  2009-12-08 21:23               ` Pascal J. Bourguignon
  2009-12-08 23:48               ` Matthew Dempsky
  2009-12-14 13:51             ` David Kastrup
  1 sibling, 2 replies; 41+ messages in thread
From: Barry Margolin @ 2009-12-08 20:48 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 20:48             ` Barry Margolin
@ 2009-12-08 21:23               ` Pascal J. Bourguignon
  2009-12-09 16:16                 ` Stefan Monnier
  2009-12-08 23:48               ` Matthew Dempsky
  1 sibling, 1 reply; 41+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-08 21:23 UTC (permalink / raw)
  To: help-gnu-emacs

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__


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 20:48             ` Barry Margolin
  2009-12-08 21:23               ` Pascal J. Bourguignon
@ 2009-12-08 23:48               ` Matthew Dempsky
  2009-12-09  8:05                 ` Andreas Röhler
  1 sibling, 1 reply; 41+ messages in thread
From: Matthew Dempsky @ 2009-12-08 23:48 UTC (permalink / raw)
  To: Barry Margolin; +Cc: help-gnu-emacs

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.




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 23:48               ` Matthew Dempsky
@ 2009-12-09  8:05                 ` Andreas Röhler
  2009-12-09 12:56                   ` Juanma Barranquero
  0 siblings, 1 reply; 41+ messages in thread
From: Andreas Röhler @ 2009-12-09  8:05 UTC (permalink / raw)
  To: help-gnu-emacs

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






^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09  8:05                 ` Andreas Röhler
@ 2009-12-09 12:56                   ` Juanma Barranquero
  2009-12-09 17:33                     ` Andreas Röhler
       [not found]                     ` <mailman.12606.1260380004.2239.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 41+ messages in thread
From: Juanma Barranquero @ 2009-12-09 12:56 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-08 21:23               ` Pascal J. Bourguignon
@ 2009-12-09 16:16                 ` Stefan Monnier
  0 siblings, 0 replies; 41+ messages in thread
From: Stefan Monnier @ 2009-12-09 16:16 UTC (permalink / raw)
  To: help-gnu-emacs

> 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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 12:56                   ` Juanma Barranquero
@ 2009-12-09 17:33                     ` Andreas Röhler
  2009-12-09 18:07                       ` Matthew Dempsky
                                         ` (3 more replies)
       [not found]                     ` <mailman.12606.1260380004.2239.help-gnu-emacs@gnu.org>
  1 sibling, 4 replies; 41+ messages in thread
From: Andreas Röhler @ 2009-12-09 17:33 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: help-gnu-emacs

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
> 







^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 17:33                     ` Andreas Röhler
@ 2009-12-09 18:07                       ` Matthew Dempsky
  2009-12-09 18:13                         ` tomas
                                           ` (2 more replies)
  2009-12-09 18:11                       ` tomas
                                         ` (2 subsequent siblings)
  3 siblings, 3 replies; 41+ messages in thread
From: Matthew Dempsky @ 2009-12-09 18:07 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 17:33                     ` Andreas Röhler
  2009-12-09 18:07                       ` Matthew Dempsky
@ 2009-12-09 18:11                       ` tomas
  2009-12-10  3:05                       ` Kevin Rodgers
       [not found]                       ` <mailman.12630.1260414617.2239.help-gnu-emacs@gnu.org>
  3 siblings, 0 replies; 41+ messages in thread
From: tomas @ 2009-12-09 18:11 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 18:07                       ` Matthew Dempsky
@ 2009-12-09 18:13                         ` tomas
  2009-12-09 18:59                         ` Andreas Röhler
       [not found]                         ` <mailman.12615.1260385212.2239.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 41+ messages in thread
From: tomas @ 2009-12-09 18:13 UTC (permalink / raw)
  To: Matthew Dempsky; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 18:07                       ` Matthew Dempsky
  2009-12-09 18:13                         ` tomas
@ 2009-12-09 18:59                         ` Andreas Röhler
  2009-12-09 21:15                           ` Matthew Dempsky
       [not found]                         ` <mailman.12615.1260385212.2239.help-gnu-emacs@gnu.org>
  2 siblings, 1 reply; 41+ messages in thread
From: Andreas Röhler @ 2009-12-09 18:59 UTC (permalink / raw)
  To: Matthew Dempsky; +Cc: help-gnu-emacs

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
> 





^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]                     ` <mailman.12606.1260380004.2239.help-gnu-emacs@gnu.org>
@ 2009-12-09 19:08                       ` Frank Fredstone
  2009-12-10 19:25                         ` Andreas Röhler
       [not found]                         ` <mailman.12689.1260473128.2239.help-gnu-emacs@gnu.org>
  2009-12-09 21:33                       ` Stefan Monnier
  1 sibling, 2 replies; 41+ messages in thread
From: Frank Fredstone @ 2009-12-09 19:08 UTC (permalink / raw)
  To: help-gnu-emacs

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



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 18:59                         ` Andreas Röhler
@ 2009-12-09 21:15                           ` Matthew Dempsky
  0 siblings, 0 replies; 41+ messages in thread
From: Matthew Dempsky @ 2009-12-09 21:15 UTC (permalink / raw)
  To: help-gnu-emacs

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.




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]                     ` <mailman.12606.1260380004.2239.help-gnu-emacs@gnu.org>
  2009-12-09 19:08                       ` Frank Fredstone
@ 2009-12-09 21:33                       ` Stefan Monnier
  2009-12-10  6:38                         ` Andreas Röhler
  1 sibling, 1 reply; 41+ messages in thread
From: Stefan Monnier @ 2009-12-09 21:33 UTC (permalink / raw)
  To: help-gnu-emacs

> 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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]                         ` <mailman.12615.1260385212.2239.help-gnu-emacs@gnu.org>
@ 2009-12-10  0:22                           ` Barry Margolin
  0 siblings, 0 replies; 41+ messages in thread
From: Barry Margolin @ 2009-12-10  0:22 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 17:33                     ` Andreas Röhler
  2009-12-09 18:07                       ` Matthew Dempsky
  2009-12-09 18:11                       ` tomas
@ 2009-12-10  3:05                       ` Kevin Rodgers
       [not found]                       ` <mailman.12630.1260414617.2239.help-gnu-emacs@gnu.org>
  3 siblings, 0 replies; 41+ messages in thread
From: Kevin Rodgers @ 2009-12-10  3:05 UTC (permalink / raw)
  To: help-gnu-emacs

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





^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]                       ` <mailman.12630.1260414617.2239.help-gnu-emacs@gnu.org>
@ 2009-12-10  5:34                         ` Stefan Monnier
  2009-12-10 10:01                           ` tomas
  0 siblings, 1 reply; 41+ messages in thread
From: Stefan Monnier @ 2009-12-10  5:34 UTC (permalink / raw)
  To: help-gnu-emacs

> 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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 21:33                       ` Stefan Monnier
@ 2009-12-10  6:38                         ` Andreas Röhler
  0 siblings, 0 replies; 41+ messages in thread
From: Andreas Röhler @ 2009-12-10  6:38 UTC (permalink / raw)
  To: help-gnu-emacs

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







^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-10  5:34                         ` Stefan Monnier
@ 2009-12-10 10:01                           ` tomas
  2009-12-10 11:00                             ` Andreas Politz
       [not found]                             ` <mailman.12651.1260442881.2239.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 41+ messages in thread
From: tomas @ 2009-12-10 10:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-10 10:01                           ` tomas
@ 2009-12-10 11:00                             ` Andreas Politz
  2009-12-11  4:37                               ` Kevin Rodgers
       [not found]                             ` <mailman.12651.1260442881.2239.help-gnu-emacs@gnu.org>
  1 sibling, 1 reply; 41+ messages in thread
From: Andreas Politz @ 2009-12-10 11:00 UTC (permalink / raw)
  To: help-gnu-emacs

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






^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-09 19:08                       ` Frank Fredstone
@ 2009-12-10 19:25                         ` Andreas Röhler
  2009-12-10 23:41                           ` Juanma Barranquero
       [not found]                         ` <mailman.12689.1260473128.2239.help-gnu-emacs@gnu.org>
  1 sibling, 1 reply; 41+ messages in thread
From: Andreas Röhler @ 2009-12-10 19:25 UTC (permalink / raw)
  To: help-gnu-emacs

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






^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]                         ` <mailman.12689.1260473128.2239.help-gnu-emacs@gnu.org>
@ 2009-12-10 20:40                           ` Frank Fredstone
  0 siblings, 0 replies; 41+ messages in thread
From: Frank Fredstone @ 2009-12-10 20:40 UTC (permalink / raw)
  To: help-gnu-emacs

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.



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-10 19:25                         ` Andreas Röhler
@ 2009-12-10 23:41                           ` Juanma Barranquero
  0 siblings, 0 replies; 41+ messages in thread
From: Juanma Barranquero @ 2009-12-10 23:41 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
  2009-12-10 11:00                             ` Andreas Politz
@ 2009-12-11  4:37                               ` Kevin Rodgers
  0 siblings, 0 replies; 41+ messages in thread
From: Kevin Rodgers @ 2009-12-11  4:37 UTC (permalink / raw)
  To: help-gnu-emacs

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





^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]           ` <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>
  2009-12-08 20:48             ` Barry Margolin
@ 2009-12-14 13:51             ` David Kastrup
  1 sibling, 0 replies; 41+ messages in thread
From: David Kastrup @ 2009-12-14 13:51 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]         ` <mailman.12517.1260268988.2239.help-gnu-emacs@gnu.org>
@ 2009-12-14 13:53           ` David Kastrup
  0 siblings, 0 replies; 41+ messages in thread
From: David Kastrup @ 2009-12-14 13:53 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: string-match bug?
       [not found]                             ` <mailman.12651.1260442881.2239.help-gnu-emacs@gnu.org>
@ 2009-12-14 13:59                               ` David Kastrup
  0 siblings, 0 replies; 41+ messages in thread
From: David Kastrup @ 2009-12-14 13:59 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2009-12-14 13:59 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.12437.1260197731.2239.help-gnu-emacs@gnu.org>
2009-12-07 15:08 ` string-match bug? Colin S. Miller
2009-12-07 15:25   ` Colin S. Miller
2009-12-07 20:37     ` Andreas Röhler
2009-12-07 21:23       ` Matthew Dempsky
2009-12-08 10:42         ` Andreas Röhler
2009-12-08 11:35           ` Juanma Barranquero
2009-12-08 11:50           ` Peter Münster
     [not found]           ` <mailman.12522.1260273034.2239.help-gnu-emacs@gnu.org>
2009-12-08 15:56             ` Stefan Monnier
     [not found]         ` <mailman.12517.1260268988.2239.help-gnu-emacs@gnu.org>
2009-12-14 13:53           ` David Kastrup
     [not found]       ` <mailman.12469.1260221021.2239.help-gnu-emacs@gnu.org>
2009-12-08  3:22         ` Barry Margolin
2009-12-08 10:50           ` Andreas Röhler
2009-12-08 11:31             ` Peter Dyballa
2009-12-08 13:55               ` Andreas Röhler
     [not found]           ` <mailman.12518.1260269458.2239.help-gnu-emacs@gnu.org>
2009-12-08 20:48             ` Barry Margolin
2009-12-08 21:23               ` Pascal J. Bourguignon
2009-12-09 16:16                 ` Stefan Monnier
2009-12-08 23:48               ` Matthew Dempsky
2009-12-09  8:05                 ` Andreas Röhler
2009-12-09 12:56                   ` Juanma Barranquero
2009-12-09 17:33                     ` Andreas Röhler
2009-12-09 18:07                       ` Matthew Dempsky
2009-12-09 18:13                         ` tomas
2009-12-09 18:59                         ` Andreas Röhler
2009-12-09 21:15                           ` Matthew Dempsky
     [not found]                         ` <mailman.12615.1260385212.2239.help-gnu-emacs@gnu.org>
2009-12-10  0:22                           ` Barry Margolin
2009-12-09 18:11                       ` tomas
2009-12-10  3:05                       ` Kevin Rodgers
     [not found]                       ` <mailman.12630.1260414617.2239.help-gnu-emacs@gnu.org>
2009-12-10  5:34                         ` Stefan Monnier
2009-12-10 10:01                           ` tomas
2009-12-10 11:00                             ` Andreas Politz
2009-12-11  4:37                               ` Kevin Rodgers
     [not found]                             ` <mailman.12651.1260442881.2239.help-gnu-emacs@gnu.org>
2009-12-14 13:59                               ` David Kastrup
     [not found]                     ` <mailman.12606.1260380004.2239.help-gnu-emacs@gnu.org>
2009-12-09 19:08                       ` Frank Fredstone
2009-12-10 19:25                         ` Andreas Röhler
2009-12-10 23:41                           ` Juanma Barranquero
     [not found]                         ` <mailman.12689.1260473128.2239.help-gnu-emacs@gnu.org>
2009-12-10 20:40                           ` Frank Fredstone
2009-12-09 21:33                       ` Stefan Monnier
2009-12-10  6:38                         ` Andreas Röhler
2009-12-14 13:51             ` David Kastrup
2009-12-07 14:55 Andreas Roehler
2009-12-07 15:31 ` Pierre Lorenzon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).