1. RE: match() (not short, he he)
Hello there,
In addtion to the other interesting posts...
match("",s)
cant return a number greater then zero because
that interpretation of the match command would
only be valid when you assume that the first
element of s is a null sequence, and that's not
really true at all.
Lets say we allow match to return a 1 for this case,
then this would lead to code like this:
s="xyz"
i=match("","xyz")
--i is now equal to the number 1
printf(1,"%s",s[i])
which would print the first character
of the sequence s, which would not be
the null sequence "".
If we had found the correct sequence,
the printf statement would have printed
the null sequence, which is not the same
as printing an 'x'.
In the remainder of this post, i'll show why the function
match(s1,s2)
with either or both args equal to the null sequence ""
should return a zero.
A sequence, in it's more basic definition, is a container just like
any other variable.
It can be an empty container, or a container with something inside it.
If it's an empty container, it cant hold anything of whatever is
inside of a container that is NOT empty. This means that
an empty container can NEVER contain anything that a non empty
container contains.
This applies even if the containers themselves can contain other
containers. If there is nothing within the internal containers,
then the most external container also contains nothing.
In the case of 'match', we want to know what is the best value
to return for cases when one or both operators are null, or
empty containers:
retv=match(container1,container2)
Since an empty container cant possibly have anything that a non empty
container has in it,
match("abc","")
already returns a zero in Euphoria.
This leaves the two cases,
match("","")
which is almost like
match("abc","")
which should both return a zero, because you cant find anything
within a container that doesnt have anything in it, even if
the first container also doesnt have anything in it,
and
match("","abc")
which should also return a zero because you cant find
the lack of anything inside of a container that already
contains something.
In spite of this clear viewpoint, it might be still possible to
argue against the simple conclusions drawn from this
on the basis that calling the sequences 'containers' is still just
another abstraction, no better than:
--------------------------------------------------------------------------
match("abc","")
"If you dont find something within that which has nothing,
you havent found anything, and so you have found zero of anything".
match("","")
It's questionable if we could really find nothing among nothing, so:
"If you couldnt find nothing within that which already has nothing,
you have still found nothing, which is still zero of anything",
and
"Even if you could find nothing among that which has nothing, you would
have still found nothing, which is indeed still zero of anything".
match("","abc")
"If you are looking for nothing within that which has something, you
wont find it, and so you have found zero of anything"
--------------------------------------------------------------------------
So i'll present more conclusive evidence why
match("","abc")
and
match("","")
should both also return a zero.
Main reasons for a change:
1. match("abc","") already returns a zero.
2. 'nothing' is not part of 'something', so it cant be there.
Validating supplementary statement:
3. no existing code would break.
[1]
match("abc","")
returns a zero already.
This means the language already admits that 'nothing' is a valid
argument, otherwise it would also trigger an error.
This means as it stands right now,
"It's ok to look for something within nothing and not find it,
but it's not ok to look for nothing within something".
[2]
'nothing' is not part of 'something' in the computer world,
so it cant ever be found and so a zero return value is warranted.
[3]
No immediate existing code would break, nor would any
simply modified code break if it was written correctly in
the first place. Existing code cant contain sequences
which ever reach null "" (match("","abc")) or else an error
would have stopped their program and they would have corrected it.
Slightly modified code might then reach a state where at
least one variable reaches the value "" within a match() call,
which would then return a zero. Since the code would have
to be able to respond to a case where match("abc","") could
come up, it would already be able to respond to a zero returned
from match() for the new case of "" for the first op.
Really though, match(object1,object2) should be the ultimate goal
of the language. I cant think of a reason why you shouldnt be
able to look for 'a' in "abc" can anyone else?
Especially since you can fool it:
i=match('a'&"","abc") -- haha, fooled you 'match()' !
--i comes out to 1
I am therefore asserting two things to be correct:
1. Changing 'match' to return a zero when its first member
is "" is the best way to handle the return value.
2. Changing 'match' as #1 states wont break any existing code.
Note that im not just saying "change the match function because it's
better",
Im also asserting that this change wont break any existing code.
For one last note, the function:
global function Match(sequence a, sequence b)
if length(a)<1 then
return 0
end if
return match(a,b)
end function
can be used as a replacement for match() and also wont
break any existing code!
Any arguments? 
Take care for now,
Al
2. RE: match() (not short, he he)
- Posted by gertie at visionsix.com
May 26, 2003
On 26 May 2003, at 16:00, Al Getz wrote:
A nice post. But i just thought of something. All the previous posts i read on
this (mine included) worked with *strings*, not nested sequences. What
about: match("",{"k","","at"}) ?
Kat
3. RE: match() (not short, he he)
gertie at visionsix.com wrote:
>
>
> On 26 May 2003, at 16:00, Al Getz wrote:
>
> A nice post. But i just thought of something. All the previous posts i
> read on
> this (mine included) worked with *strings*, not nested sequences. What
> about: match("",{"k","","at"}) ?
>
> Kat
>
Hello again,
I think you meant
match({""},{"k","","at"})
right?
I meant to mention that i noticed that match works for
match({""},{"k","a","t"})
but not for
match("","kat")
which says that not that much thought went into
the match function to begin with.
The point that you brought up is useful when you want to
find, say, maybe an already empty sequence within a
sequence of sequences, so that you can store something
there. This means we couldnt declare outer most sequences
as empty if they at least contain an empty sequence.
In other words, the sequence
{""}
cant be said to be empty, because this sequence
contains an empty sequence which is something
in this case, unlike when we only have "".
Indeed,
length({""})
returns 1, which says something is there also, while
length("")
returns 0, which says nothing is there at all.
In light of the previous post, this means a sequence
that has at least one empty sequence in it "has something
contained within it and so there is indeed something that
can be not only searched for, but also that can be found".
I was therefore incorrect when i stated something to
the contrary.
As far as "" by itself goes, as in
match("",something)
this should always return a zero because "" implies
a null character and for the reasons in the last post,
so i dont change any of my assertions from the last post.
match({""}, something)
will have to stay the same as it is, contrary to what
can be concluded from the statement that
'an empty sequence within a sequence is still an empty
sequence'.
If you are saying that
match("",{"a","","c"})
should return the number 2, then i would argue that
match("c",{"a","","c"})
would return the number 3, which it really shouldnt
because
match("c","axc")
returns the number 3.
When we deal with sequences, i would think we should have
to deal with them level by level, comparing a level of
one string only to a level of another string unless we
have the luxury of declaring a new, more advanced function
to handle a level switch or return multiple values.
If you are instead saying that
match("c",sequence)
should search the entire sequence for a 'c', regardless of
level, then you also have to return more then one value to
indicate where the 'c' was actually found, and this, again,
requires a more sophisticated function. Granted, it would
be very useful i would think, especially since you could
then use the results to access the character or string.
If match returned a sequence like {1,2} you could use
that to access the sequence by
thing=seq[1][2]
perhaps.
That would be pretty interesting, except it would take lots
of time to find some things in a complex nested sequence.
------>
What it boils down too is the replacement of the
match function with the Match function in the last post.
All this does to modify the current match() is to
check the first value for "", and if it's lenght is
equal to zero, return a zero. Everything else stays the same.
If it's length isnt zero (even contains an empty inside
another sequence) then it defaults to call match().
I like your idea of being able to look for empty sequences
very much, but i dont think it could apply for the
empty sequence "" unless the match function suddenly gets
more sophisticated as i was saying.
Any other interesting ideas like that?
I hope you have some more, i'd like to hear them too
Take care for now,
Al
4. RE: match() (not short, he he)
- Posted by gertie at visionsix.com
May 26, 2003
On 26 May 2003, at 18:49, Al Getz wrote:
>
>
> gertie at visionsix.com wrote:
> >
> >
> > On 26 May 2003, at 16:00, Al Getz wrote:
> >
> > A nice post. But i just thought of something. All the previous posts i
> > read on
> > this (mine included) worked with *strings*, not nested sequences. What
> > about: match("",{"k","","at"}) ?
> >
> > Kat
> >
>
> Hello again,
>
> I think you meant
>
> match({""},{"k","","at"})
>
> right?
>
> I meant to mention that i noticed that match works for
> match({""},{"k","a","t"})
Because as you point out later, {""} isn't an empty or null {}.
> length({""})
> returns 1, which says something is there also, while
> length("")
> returns 0, which says nothing is there at all.
I use length() a lot, just for this sort of fault tolerance in ""
strings/sequences.
> Any other interesting ideas like that?
> I hope you have some more, i'd like to hear them too
Yes, strangely enough, i have other ideas. 
i'd prefer
match('a',"something")
to not fail because of the alledgedly abhorent reason that 'a' isn't a sequence.
It's too late to change, but i'd prefer
match('a',"kat")
to return 2, since the 'a' in "kat" is an atom. And
match("b",{"a",'b',"b","c"})
to return 3, because the third element "b" in the second parameter of match
is a sequence, and the 2nd parameter isn't. I haveto test parms in match() for
that first parm being a sequence all the time too.
Kat
5. RE: match() (not short, he he)
>Kat wrote:
>
>Yes, strangely enough, i have other ideas.
>
>i'd prefer
>
>match('a',"something")
>
>to not fail because of the alledgedly abhorent reason that 'a' isn't a
>sequence.
>It's too late to change, but i'd prefer
>
>match('a',"kat")
>
>to return 2, since the 'a' in "kat" is an atom. And
>
>match("b",{"a",'b',"b","c"})
>to return 3, because the third element "b" in the second parameter of
>match
>is a sequence, and the 2nd parameter isn't. I haveto test parms in
>match() for
>that first parm being a sequence all the time too.
>
>Kat
>
Hello again Kat,
I dont think any of your ideas have been strange, rather,
i think they hint on what all Euphoria users want in the
language in one form or another.
I dont think i made it quite that clear why i was saying
match("b",{"a","b","c"})
should return 0 and not the number 3 though.
The main reason is that match now returns a single number,
which is a single dimensional quantity. The reason it has
to be single dimensional is because match works on only
one level of the sequence at a time. The level it searches
in the second sequence is always the same as the level
of the first sequence. It has to be this way, or else we
wouldnt know where it was looking, and the number it returned
would be meaningless to us.
A simple example:
match("b",{"abc"})
match("b",{"a","b","c"})
match("b",{"ab","c","d"})
match("b",{{"a","b","c"}})
These cant all return the number 2, can they?
To find out, all we have to do is try using the
proposed new results in a program and see what happens.
In the following code, all i have done is forced match
to return the number 2 for every case which i 'think'
you want to see the number 2 returned. I did this
simply by setting i=2 AFTER the match calls.
By inspecting these results below, you will see that
there is only one case where match truely returns
the number 2, and it does appear to be correct.
Let's try these one at a time and see...
[1]
s="abc"
i=match("b",s) --returns 2
i=2
?s[i] --prints >98< --works fine!
[2]
s={"a","b","c"}
i=match("b",s) --returns 0
i=2
?s[i] --prints >{98}< --is this correct?
[3]
s={"ab","c","b"}
i=match("b",s) --returns 0
i=2
?s[i] --prints >{99}< --this is clearly incorrect!
[4]
s={{"a","b","c"}}
i=match("b",s) --returns 0
i=2
?s[i] --subscript value 2 is out of bounds, reading from a sequence of
length 1
Nobody seems to be saying that #1 above isnt correct, and that is
the only one that works correctly, really. match returns 2 anyway.
In #2, match returns 0 and when we force it to be a 2 we end
up printing the correct number, 98, but it's inside of a sequence.
Arguably, this may be interpreted to be correct in some cases, but
in #3, when we apply the same idea, we get a totally incorrect
result, as now we end up printing the number 99 inside a sequence,
which is totally wrong. We end up printing the 'c' instead of what
we were really looking for, the 'b'.
in #4, we get really bad results, but again it is arguable that
?s[i] with i=0 would have done the same thing. This says that
our code has to be able to handle the possibility of match returning
a zero, but we still havent found the "b" nested inside of s in this
example, so this fails also.
The reason why some of these tests fail and some return incorrect
results is because match, right now, only returns a single number.
If match could return a sequence, this would change and what you
want to do would work.
Repeating #4 allowing match to return a sequence:
[4r]
s={{"a","b","c"}}
i=match("b",s) --returns 0
ss={1,2,1} --'force' match to return sequence
--now let's use this sequence to try to print the b:
?s[ss[1]][ss[2]][ss[3]] --prints >98< --yeahhh!
Finally, we found the correct value within {{"a","b","c"}}
but it took three dimensions to do it.
Granted this would work, but match would have to be
seriously updated
Also, once found, it would be hard as heck to find the
next occurance of "b" wouldnt it? Try that
match() would also have to be updated to accept a
starting point in the sequence, something i have
always wanted in "find()". That's another story though
------->
All i was asking for is that match to return a zero when
the first sequence is null "" (exactly) with no regard
for the second sequence. Without this, we can never
use the following line in our code:
while match(s1,s2) do
for fear that s1 might become the null sequence at some point,
as in:
while match(s1,s2) do
--reduce length of s1 and do other stuff
end while
Take care for now,
Al
6. RE: match() (not short, he he)
- Posted by gertie at visionsix.com
May 27, 2003
On 27 May 2003, at 8:39, Al Getz wrote:
>
>
> >Kat wrote:
> >
> >Yes, strangely enough, i have other ideas.
> >
> >i'd prefer
> >
> >match('a',"something")
> >
> >to not fail because of the alledgedly abhorent reason that 'a' isn't a
> >sequence.
> >It's too late to change, but i'd prefer
> >
> >match('a',"kat")
> >
> >to return 2, since the 'a' in "kat" is an atom. And
> >
> >match("b",{"a",'b',"b","c"})
>
> >to return 3, because the third element "b" in the second parameter of
> >match
> >is a sequence, and the 2nd parameter isn't. I haveto test parms in
> >match() for
> >that first parm being a sequence all the time too.
> >
> >Kat
> >
>
> Hello again Kat,
>
> I dont think any of your ideas have been strange, rather,
> i think they hint on what all Euphoria users want in the
> language in one form or another.
>
> I dont think i made it quite that clear why i was saying
> match("b",{"a","b","c"})
> should return 0 and not the number 3 though.
You mean 2 ? I believe it should return 2, because match() currently looks at
the top layer of the top sequence, and no deeper, which makes sense. The {
} is the top layer, and it contains as it's atoms the three sequences "a" , "b",
and "c". You are looking for a "b", and there is a "b" laying right there, plain
as day. I can see it, i'd expect match() to see it. If i were looking for a 'b'
in
that example, i'd expect a 0 to be returned, because there is no top layer
atomic 'b' there, it's inside a sequence, which is like another { }, which you
agree(?) should not be looked into. There is, however a 'b' in "abc", because
that is like an {'a','b','c'}.
> The main reason is that match now returns a single number,
> which is a single dimensional quantity. The reason it has
> to be single dimensional is because match works on only
> one level of the sequence at a time. The level it searches
> in the second sequence is always the same as the level
> of the first sequence. It has to be this way, or else we
> wouldnt know where it was looking, and the number it returned
> would be meaningless to us.
I agree.
> A simple example:
-- I put in what i would expect
> match("b",{"abc"}) -- 0
-- the "abc" is sitting on the top layer of the { }, and is the one and only
element of the { }, and it's not a "b". {"abc"} is a list of one sequence.
-- and, match('b',{"abc"}) = 0
-- for the same reason
-- but, match('b',"abc") = 2
-- because you are looking for an atom in a list of atoms, one of which is a
'b'.
> match("b",{"a","b","c"}) -- 2
--why? because the { } makes one object level, the top level, and holds it's
contents. The "b" in the { } is the same as the "b" you are looking for.
> match("b",{"ab","c","d"}) -- 0
because that b inside the "ab" is in an obvious sequence, and even tho it is
an atom, you are looking for a "b", not a 'b'.
> match("b",{{"a","b","c"}}) -- 0
There you simply have it nested too deeply. And you know that.
> These cant all return the number 2, can they?
Only one of those examples should.
<snip>
> In #2, match returns 0 and when we force it to be a 2 we end
> up printing the correct number, 98, but it's inside of a sequence.
> Arguably, this may be interpreted to be correct in some cases, but
but it is a sequence that is exactly what you are looking for.
> in #3, when we apply the same idea, we get a totally incorrect
> result, as now we end up printing the number 99 inside a sequence,
> which is totally wrong. We end up printing the 'c' instead of what
> we were really looking for, the 'b'.
No, no, no! In #3, you are looking for a sequence, and there is no "b" in #3.
Your first param is a "b", you are looking for a top level object that is a
sequence. The "ab" is a top level object inside the { } that forms the 2nd
param, but it isn't "b". You cannot pick {"ab"} as finding "b", any more than
you can do this:
atom x x = 65 OR 128
? match('A',x)
and see 'A' printed out, since the bit pattern for 'A' is in x. Besides, again,
in
{"ab"} that b is an atom, and you are looking for a sequence.
> in #4, we get really bad results, but again it is arguable that
> ?s[i] with i=0 would have done the same thing.
Well, i'd like to see that return a null or nil or "" or '' or something, rather
than
crash the interpreter.
> This says that
> our code has to be able to handle the possibility of match returning
> a zero, but we still havent found the "b" nested inside of s in this
> example, so this fails also.
>
> The reason why some of these tests fail and some return incorrect
> results is because match, right now, only returns a single number.
> If match could return a sequence, this would change and what you
> want to do would work.
Too confusing. Interesting, but then you would be parsing the reply from
match(), even if you didn't want to drill down into a deep nest. If i want to
run
match() on a level deeper than the top, it's just as easy to spec the level i
want searched thru, easier than allowing for endless levels of nesting in a
match() return.
<snip>
> All i was asking for is that match to return a zero when
> the first sequence is null "" (exactly) with no regard
> for the second sequence. Without this, we can never
> use the following line in our code:
>
> while match(s1,s2) do
>
> for fear that s1 might become the null sequence at some point,
> as in:
>
> while match(s1,s2) do
> --reduce length of s1 and do other stuff
> end while
I agree, extra tests must be written each time i use match(), because sure
as heck it will crash at the worst time, in unforeseen conditions, with
parameters that any human would figure out instantly.
Kat
7. RE: match() (not short, he he)
Hello again Kat,
>Kat wrote:
>match("b",{{"a","b","c"}}) -- 0
>There you simply have it nested too deeply. And you know that.
>
Yes i know that and you know that, but the language doesnt.
It doesnt matter how deeply you nest something, the
language has to have a way of conveying the result to the
program that makes sense for ALL possible cases, not just
some...
i=match("b","abc"}}) -- ret 2
i=match("b",{"a","b","c"}) --ret 2
i=match("b",{{"a","b","c"}}) --ret 2
i=match("b",{{{"a","b","c"}}}) --ret 2
Is this what you would like to see??
or
are you saying you only want to see this:
i=match("b","abc"}}) -- ret 2
i=match("b",{"a","b","c"}) --ret 2
i=match("b",{{"a","b","c"}}) --ret 0
i=match("b",{{{"a","b","c"}}}) --ret 0
??
You really have to stick your result into some code
to find out what really happens next, once you
think you have determined a better return result.
Set i equal to whatever you think it should be for
several cases and see what happens.
Take care,
Al
8. RE: match() (not short, he he)
- Posted by gertie at visionsix.com
May 27, 2003
On 27 May 2003, at 11:16, Al Getz wrote:
>
>
> Hello again Kat,
>
>
> >Kat wrote:
> >match("b",{{"a","b","c"}}) -- 0
> >There you simply have it nested too deeply. And you know that.
> >
>
> Yes i know that and you know that, but the language doesnt.
It doesn't??? When i run it, it returns zero! And it should return zero! If
your's
doesn't, you better contact Rob, your interpreter has a bug somewhere!
> It doesnt matter how deeply you nest something, the
> language has to have a way of conveying the result to the
> program that makes sense for ALL possible cases, not just
> some...
That doesn't mean it should give errors!
> i=match("b","abc"}}) -- ret 2
I say no. The b in "abc" looks like an atom to me, and you told match to look
for a "b", which is a sequence.
> i=match("b",{"a","b","c"}) --ret 2
Yes.
> i=match("b",{{"a","b","c"}}) --ret 2
> i=match("b",{{{"a","b","c"}}}) --ret 2
No, and no.
> You really have to stick your result into some code
> to find out what really happens next, once you
> think you have determined a better return result.
Doesn't matter what i code, Rob isn't going to put it into the official
Euphoria,
is he?
Kat
9. RE: match() (not short, he he)
gertie at visionsix.com wrote:
>
>
> On 27 May 2003, at 11:16, Al Getz wrote:
>
> >
> > Hello again Kat,
> >
> >
> > >Kat wrote:
> > >match("b",{{"a","b","c"}}) -- 0
> > >There you simply have it nested too deeply. And you know that.
> > >
> >
> > Yes i know that and you know that, but the language doesnt.
>
> It doesn't??? When i run it, it returns zero! And it should return zero!
> If your's
> doesn't, you better contact Rob, your interpreter has a bug somewhere!
What was meant there was that the language doesnt know
what level you want it to look though. It cant look
at arbitrary levels unless it returns the level also,
and since there can be multiple levels, there would have
to be multiple return values.
You cant have both.
Either
match("b",{"a","b","c"})
returns a 2 or
match("b","abc"})
returns a 2,
but not both.
Right now, the second case returns 2 and that
has to stay like that, but
match("",...)
can be changed to return a zero without breaking code.
I dont know why i have to keep saying this?
Take care,
Al
10. RE: match() (not short, he he)
Derek Parnell wrote:
>
>
> Well that seems to be true with nearly all previous suggestions.
> However,
> one of my bosses used to say "Trends are not Destiny".
>
> I guess what we are really saying is
> 1) that it would be nice if Euphoria would return a value, say 0, for
> zero-length LHS parameters in match() rather than crashing.
> 2) If the LHS parameter of match() is an atom, treat it as if it was a
> single item sequence.
>
> Neither of these would break existing code.
>
> ----------------
> cheers,
> Derek Parnell
>
>
Yes, i have been saying that all along
I'd even be happy to see #1 alone.
If something makes the language better without breaking
existing code, why not use it?
Take care for now,
Al
11. RE: match() (not short, he he)
- Posted by gertie at visionsix.com
May 27, 2003
On 27 May 2003, at 12:44, Al Getz wrote:
<snip>
> match("",...)
>
> can be changed to return a zero without breaking code.
> I dont know why i have to keep saying this?
I don't know why you feel you must keep saying that line, i agree with that
one, 100%. I always have.
Kat
12. RE: match() (not short, he he)
> On 27 May 2003, at 11:16, Al Getz wrote:
>
>
>> Hello again Kat,
>>
>>
>> >Kat wrote:
>> >match("b",{{"a","b","c"}}) -- 0
>> >There you simply have it nested too deeply. And you know that.
>> >
>
>> Yes i know that and you know that, but the language doesnt.
>
>
> It doesn't??? When i run it, it returns zero! And it should return zero! If
> your's
> doesn't, you better contact Rob, your interpreter has a bug somewhere!
>
>
>> It doesnt matter how deeply you nest something, the
>> language has to have a way of conveying the result to the
>> program that makes sense for ALL possible cases, not just
>> some...
>
>
> That doesn't mean it should give errors!
>
>
>> i=match("b","abc"}}) -- ret 2
>
>
> I say no. The b in "abc" looks like an atom to me, and you told match to look
> for a "b", which is a sequence.
>
>
>> i=match("b",{"a","b","c"}) --ret 2
>
>
> Yes.
>
>
>> i=match("b",{{"a","b","c"}}) --ret 2
>> i=match("b",{{{"a","b","c"}}}) --ret 2
>
>
> No, and no.
>
I agree with all 4 statements: only #2 shoud return 2, all others 0.
And it means that, contrary to what I said before, match() must behave
differently if first argument is an atom or a sequence. But logically it
shouldn't throw an error when first arg is an atom. Thus
i=match('b',"abc") --ret 2
which means that match() falls back on find() in this case.
CChris
13. RE: match() (not short, he he)
Hello again,
I see now why there is so much confusion here.
We are attempting to understand something basic,
yet confusing the issue by the using something
that belongs to another issue in general that,
in itself, is also a little hard to understand.
Once we remove this secondary issue from all
the examples, the underlying concepts shine through
bright and clear.
The secondary issue i was talking about is that
of using quotes around characters like "b", "abc"
etc. This in itself clouds the issue, and so if
we remove the use of quotes for all of the remaining
discussions, the concepts will show through much
better. Once we have determined for sure how
things work without using ANY quotes, then we can
come back and again look at cases with quotes, but
im sure it will be much simpler then.
Ok, so leaving the quotes out we have to use
the ascii codes to represent the characters,
such as 97,98,99, etc., but we dont even have to
use characters for now really.
With this in mind, let's repeat a couple of the
examples:
[1] match(2, {1,2,3}) --ret 0
[2] match({2}, {1,2,3}) --ret 2
[3] match({2}, {{1,2,3}}) --ret 0
Note that the level of the first arg determines where
the second arg is searched, but unfortunately, it
only works at level 1 unless you are looking for
an exact match, which will be the subject for my next
post about the problems with match.
Take care,
Al
