|
|
 | | From: | Alex McDonald | | Subject: | Re: Ambiguous SEARCH | | Date: | 9 Jan 2005 18:26:44 -0800 |
|
|
 |
Elizabeth D. Rather wrote:
>
> Well, I don't think it's at all clear. I agree with Marcel's direct
answer
> to your hypothetical, but will add that this example is an example of
what
> ANS Forth calls an "ambiguous condition" in that a zero-length string
is a
> meaningless and inappropriate argument, similar to dividing by zero.
It's
> possible that the past or a future standards body might prescribe an
> interpretation of this case, but I would personally argue against
doing so.
> Trying to prescribe consistent results for nonsensical situations is
a
> thankless chore, there are better ways to expend bandwidth.
>
> I'm perfectly happy with SwiftForth failing to find a zero-length
string. I
> think that answer is far more useful to an application than claiming
to have
> "found" something that cannot exist.
>
Except that a zero length string is a valid string in all other
circumstances, and the effect of returning found on a SEARCH is
equivalent to the regexp ^ -- something that seems quite logical.
And if you are to argue that HERE 0 as a string can't be SEARCHed
because it doesn't exist, then what should be the result of comparing
two strings that don't exist, as in HERE 0 HERE 0 COMPARE ?
--
Regards
Alex McDonald
|
|
| | From: | Jeff | | Subject: | Re: Ambiguous SEARCH | | Date: | Mon, 10 Jan 2005 05:59:19 GMT |
|
|
| Alex McDonald wrote:
> Except that a zero length string is a valid string in all other
> circumstances, and the effect of returning found on a SEARCH is
> equivalent to the regexp ^ -- something that seems quite logical.
However, searching for the regex ^ isn't the same as searching for an
empty text string. You are searching for the beginning of a string (or
line in this case), which is different. And that should match.
Jeff M.
--
http://www.retrobyte.org
mailto:massung@gmail.com
|
|
| | From: | Elizabeth D. Rather | | Subject: | Re: Ambiguous SEARCH | | Date: | Sun, 9 Jan 2005 19:01:11 -0800 |
|
|
| "Alex McDonald" wrote in message
news:1105324004.587943.168230@c13g2000cwb.googlegroups.com...
> > I'm perfectly happy with SwiftForth failing to find a zero-length
> string. I
> > think that answer is far more useful to an application than claiming
> to have
> > "found" something that cannot exist.
> >
>
> Except that a zero length string is a valid string in all other
> circumstances, and the effect of returning found on a SEARCH is
> equivalent to the regexp ^ -- something that seems quite logical.
>
> And if you are to argue that HERE 0 as a string can't be SEARCHed
> because it doesn't exist, then what should be the result of comparing
> two strings that don't exist, as in HERE 0 HERE 0 COMPARE ?
Well, if you give a 0 length string to MOVE, for example, it can do nothing,
and that makes sense, although I note that the standard says for MOVE and
its relatives, "If u is greater than zero, ...". But to search for a 0
length string is meaningless to me, whether in SEARCH, COMPARE, or anywhere
else. And I don't know whether it's really true that "a zero length string
is a valid string in all other circumstances," it's more likely that
behavior on a 0 length string just isn't described in some cases.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
|
|
| | From: | Bernd Paysan | | Subject: | Re: Ambiguous SEARCH | | Date: | Mon, 10 Jan 2005 15:26:37 +0100 |
|
|
| Elizabeth D. Rather wrote:
> But to search for a 0
> length string is meaningless to me, whether in SEARCH, COMPARE, or
> anywhere else.
For me, searching for the empty string makes perfectly sense. Take a look at
prefix?:
: prefix? ( addr1 u1 addr2 u2 -- flag ) search swap 0= and nip ;
The definition of "prefix" is obvious: A string is a prefix to another
string, when you can find a string to add to the prefix so that both
strings are equal. The empty string is prefix to any string. Therefore, the
empty string also is contained in each string, since you can construct
every string by inserting the empty string whereever you like.
The empty string is neutral to string addition. This is algebra, and
therefore, the results are obvious. Mathematically, string addition is a
half-group, i.e. it is not associative. The mathematical definition of
string search would be:
Let S and x be strings. S contains x if you can find y and z, so that
y+x+z=S. The first occurrance of x in S is the one with the smallest y.
You can define an order over strings ("lexical order"). This order defines
that when a is a prefix of b, a is smaller than b. So the COMPARE of empty
and non-empty string results in the empty string being smaller.
The empty string to string operators therefore is not like a division by 0,
but like a subtraction by 0. That's a perfectly valid operation.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
|
|
| | From: | Anton Ertl | | Subject: | Re: Ambiguous SEARCH | | Date: | Mon, 10 Jan 2005 17:38:03 GMT |
|
|
| Bernd Paysan writes:
>: prefix? ( addr1 u1 addr2 u2 -- flag ) search swap 0= and nip ;
A more efficient implementation of prefix? is:
: str= ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
compare 0= ;
: string-prefix? ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
\G Is @var{c-addr2 u2} a prefix of @var{c-addr1 u1}?
tuck 2>r min 2r> str= ;
>The empty string is neutral to string addition. This is algebra, and
>therefore, the results are obvious. Mathematically, string addition is a
>half-group, i.e. it is not associative.
String concatenation is associative (maybe you were thinking about
commutativity?), and that makes it a semigroup. It also has a neutral
element (the empty string), so it is a monoid.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html
|
|
|
