OpenEuphoria

RE: match() (not short, he he)

• Posted by gertie at visionsix.com May 27, 2003
• 419 views

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