OpenEuphoria

Re: Another Error

• Posted by Derek Parnell <ddparnell at bigpond.com> Feb 01, 2007
• 651 views

I'm not really interested in contributing to this waste of time, but in spite of
that I will respond a bit...

Robert Craig wrote:
> 
 
> Which languages are you including in your list of 
> "most other languages"? 

Those languages that have a String datatype as a built-in one.

> I know Basic works the way you would like, 
> but C/C++ (a more popular language) does not. People who come to 
> Euphoria from a Basic background are often confused by this, 
> but many other people, such as myself, who are used to C/C++, 
> think it's fine to require a function call to compare strings or 
> arrays in this way. 

I agree with you. Basic knows about strings and C/C++ does not. Strings in C/C++
are emulated as 'char' arrays that have a final char zero to mark the end of the
string. Because strings are not native to C/C++ it has been required to use
functions to implement string functionality.

However, why is the C/C++ history rather than the Basic history a better way to
compare strings; from the point of view of the writer/reader of code?

In other words, why is 

   "if equal(stringA, stringB) then" 

better than 

   "if stringA = stringB then"
?


> This is not something that Robert Craig invented, 
> all on his own, just to annoy the rest of the world. 

I fully realize that and I hope no-one assumed I meant otherwise. The annoyance
is merely an accidental side-effect of your design decision.


> > However, as Robert's philosophy on this is never going to change, 
> 
> Yeah, I guess I'm just a stubborn old fool. 

Yeah, me too.
 
> > the only safe
> > way to code equality tests in IF statements in Euphoria is this ...
> > 
> >   if equal(Correct, 'y') or equal(Correct, 'Y') then
> > 
> > which is not an intuitive alternative.
> 
> I assume you meant:
> 
>     if equal(Correct, "y") or equal(Correct, "Y") then

Thanks, that is what I meant to write.
 
> Anyway, thanks for the tutorial. I know there are newbies
> who are confused by this feature.

You're welcome. But is it better to let newbie confusion continue or to remove
the root cause of the confusion?

> For what it's worth, I'd probably code it as:
> 
>    if find('Y', upper(Correct)) then ...
> 
> which will allow the user to type any of:
>  Y
>  y  
>  yes
>  Yes
>  YES 
>  yeah
> etc.

As well as "Nay" and "No way" 

> rather than insisting that he type precisely "y" or "Y"
> (with no extra characters, leading or trailing blanks etc.).
>
> Or perhaps something like:
> 
>    if find(upper(Correct), {"Y", "YES", "OK", "OUI", "JA", "SI"}) then  

I would probably tend to write this as ...

     Correct = upper(trim(Correct)) & "N" -- Default to No.
     if find(Correct[1], "YOJS") then

but now we are dealing with User Interface issues and not the issue of the
semantics of the IF statement.

My position is clear, in my mind anyhow, that the expression in an IF statement
is intended to discover if something is true or not. And if a coder writes 'if
sequenceA = sequenceB then' they are trying to discover if its true that two
sequences contain the same value. The coder is not trying to derive a third
sequence containing 0/1 elements.

But this is where we differ. I feel that you are favouring the ease writing an
interpreter over the easy of coding in the langugage. But let's not bicker yet
again over this point. I concede that I'm not going to be able to change
anything.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell