Re: match()
Hi Al, you wrote:
> Juergen Luethje wrote:
>>
>>
>> Hi Al, you wrote:
>>
>> <snip>
>>
>>> On the other hand, returning
>>> a zero when one or both args are null wouldnt break any code.
>>>
>>> This means
>>>
>>> match("",s)
>>> match(s,"")
>>> match("","")
>>>
>>> all should return zero, without regard for what is (or isnt)
>>> contained within the sequence s.
>>
>> <snip>
>>
>> match("","") IMHO should raise an error, or return -1 (or another flag
>> to indicate an illegal operation), or return 1 (*not 0*).
>>
>> Since match("ab","ab") returns 1, because both strings are identical,
>> match() for any other two strings x and y, where equal(x,y) = 1,
>> should never return 0. IMHO.
>>
>> Best regards,
>> Juergen
>>
>> --
>> /"\ ASCII ribbon campain | |\ _,,,---,,_
>> \ / against HTML in | /,`.-'`' -. ;-;;,_
>> X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
>> / \ and unneeded MIME | '---''(_/--' `-'\_)
>>
>
> hi Juergen, i like your little pic there 
<-- begin lover of cats mode -->
Thanks.
There is also a little cat running on my desktop all the time.
In case you are (or someone else is) interested:
http://luethje.de.vu/temp/felix.zip (Freeware for 32-bit Windows, 212 KB)
<-- end lover of cats mode -->
> So far i think i've agreed with you on most issues, but
> returning 1 from match with two null sequences isnt one
> of them that i can agree on.
There may be a misunderstanding, that's not what I actually was trying
to say. I wrote:
| match("","") IMHO should raise an error, or return -1 (or another flag
| to indicate an illegal operation), or return 1 (*not 0*).
Maybe I should have written more in detail, I'll try to do so now.
My main point was, that 'match("","")' should not return 0 (I tried to
emphasize this by enclosing 'not 0' in asterisks. Besides, there are
some "or"s in that sentence. I just mentioned returning 1 as one of
several theoretical possibilities, if we only look at this 'match("","")'
example. Returning 1 for any 'match("",...)' isn't a good idea at all,
as especially Irv previously had pointed out very clearly. I had agreed
to that, and in the light of the previous discussion, I didn't think it
was necessary to emphasize it again.
> In real life, the two characters that make up the null ""
> appear as simply:
>
> ""
>
> so if you happen so spot two more, like this:
>
> ""
>
> it is very logical to say that you have found the EXACT
> same thing in the second instance as the first (above).
> To enumerate this, we could say we have found exactly one
> of these 'things' and so it would make sense to assign the
> number 1 to this circumstance.
>
> On the computer, however, it's a very different world.
> First off, we our operating within the context of a
> programming language, which has to meet certain criteria
> which is different then that in the most basic, real life
> situtation.
I totally agree. That's why I didn't mention any 'real life example',
but the fact, that *in Euphoria* equal("","") = 1.
> For one thing, we have to be consistant in whatever we do,
> or the language will have a lot of anomalies and it will
> be hard to use.
Yes, that's what I wrote.
equal("","") = 1 -- as it is now (and hopefully will remain
-- in the future)
isn't consistent with
match("","") = 0 -- what you are suggesting
If any two sequences x and y are identical, i.e. if
equal(x,y) = 1
IMHO there shouldn't be returned 0 for
match(x,y).
By trying to improve the language, you are adding a new anomaly.
That -- and nothing else -- was exactly my point.
Now following my suggestion,
match("","")
either should return -1, or raise an error. Someone (you?) previously
wrote, that returning -1 would break too much existing code.
So the best solution probably would be: Just let match() alone.
> Granted, Euphoria has some of these already,
> that's why we ended up discussing this issue, but the idea
> is to REDUCE the number of anomalies over time in order to
> perfect the language.
> How do we accomplish this?
Certainly not by adding new anomalies.
> The answer lies in discovering how the individual functions
> work as a whole, and determining which ones dont quite fit
> in as well.
>
> In this case, we are talking about the function match, which
> has to work with two sequences, and has to return a value that
> is commensurate with the code that will follow, as well as with
> other functions that use sequences.
>
> The other interesting thing about match though, is that it
> is basically searching for something, within a sequence.
> If it finds something, it returns a number from 1 to max integer.
> If it doesnt find anything, it returns a zero.
>
> Let me repeat that last line one more time:
>
> "If it doesnt find anything, it returns a zero."
>
>
> Now in the real world, when we find
> ""
> we have indeed found something, but in the Euphoria language
> when we find
> ""
> we have not found anything
> (unless it is nested inside of another sequence such as {""} ).
>
> The evidence for this lies in looking at other functions
> that use sequences.
["d" is SOMETHING]
Agreed.
["" is clearly not SOMETHING]
Agreed.
> So you see, although we have no trouble finding "" in the real world,
> perhaps in a page of text, we do have trouble finding it within a
> first level sequence that already exists in the Euphoria language.
>
>
> Now back to the match function...
>
> We found out that "" is not SOMETHING in Euphoria, it is NOTHING,
> so we cant ever hope to find it within a one level sequence.
> This means
>
> match("","")
>
> is the same as
>
> match("",s)
>
> because we wont ever find anything if we are looking for nothing.
>
> Side note:
> If we are looking though a multi level sequence
> such as {"abc","",{""}}
> match has to return a zero because of a different reason,
> namely, because the search level is different.
>
>
> If you want to assume that if you are looking though nothing in hopes
> of finding nothing and you do indeed find nothing (because after all,
> if you find nothing havent you actually found it?), that you have
> actually found something because you have found nothing, then you can
> see that this still defaults to having found NOTHING!
> The reason for this is that when you look for nothing,
> it's just an idea, not a concrete object.
>
> Not only that, in real life
> you cant actually even get as far as to look for nothing, because then
> you could say you were actually looking for something, which you werent.
> On the computer however, this isnt true, because we can actually look
> for nothing because although nothing really doesnt exist, it still has
> a representation.
>
>
> Also, as i said before, returning 0 from
>
> match("",s)
>
> where s is ANY sequence, doesnt break any existing code,
> whereas every other idea i've heard so far does, no matter
> how good (or bad) it sounded.
>
> One advantage is that you can use the line
> while match(...)
> whereas right now you cant, unless you can also make sure
> the first sequence will never be null.
>
>
> I've understood your arguements, now try to understand mine.
Of course I tried it, but I think you didn't understand my arguments.
You again and again wrote something about 'real life' etc., thereby
verbose trying to refute arguments, that I never wrote.
On the other hand, you didn't go into the only argument that I wrote.
I agree to anything that you wrote, but your mail wasn't really a reply
to my previous post.
> Take care for now,
> Al
Best regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | This message has been ROT-13 encrypted
X e-mail and news, | twice for higher security.
/ \ and unneeded MIME |
|
Not Categorized, Please Help
|
|
