OpenEuphoria

2. Re: Another Error

• Posted by c.k.lester <euphoric at cklester.com> Jan 31, 2007
• 710 views
• Last edited Feb 01, 2007

Rich Klender wrote:
> 
>         Correct = prompt_string("Is this correct? y/n")
> 
>         if Correct = 'y' or Correct = 'Y' then
>             return ReturnCode = 1   
>         end if
> The problem is in the last if/then statement, if the user inputs 'y' then it
> returns to the main program, if not I want it to fall thru and the user
> re-inputs
> the correct data.  I get the following error:
> 
> H:\test1.ex:24 in function AddFactions() 
> true/false condition must be an ATOM 
>     C = 1
>     FactionName = "asdf"
>     FactionPassword = "asdf"
>     Correct = "n"

You're trying to compare an atom (the 'y' and 'Y') and a sequence
(Correct, which is "n"); that is a no-no in Euphoria. Use either:

    if find(Correct,"Yy") then

or

    if Correct[1] = 'Y' or Correct[1] = 'y' then

4. Re: Another Error

• Posted by Derek Parnell <ddparnell at bigpond.com> Jan 31, 2007
• 732 views
• Last edited Feb 01, 2007

Rich Klender wrote:
> 
> Well, I hit another snag, if anyone would be gracious enough to help!!!
> 
> Here's the code:

I've reduced it to the problem area ... 

>     sequence Correct
>     if Correct = 'y' or Correct = 'Y' then
 
> true/false condition must be an ATOM 

This has been one of my few disappointments with Euphoria. Robert Craig, the
creator of the language, has defined the 'if' statement in a manner which most
other languages do not. Bear with me please, as I understand that this is your
first real programming effort - I may get a little technical here 

Euphoria defines the IF statement as 

   IF ::  'if' ATOMEXPRESSION 'then' 
            [ STATEMENTBLOCK ] 
            [ ELSEPHRASE ] 
          'end if'

but most other languages define it as 

   IF ::  'if' COMPARISIONEXPRESSION 'then' 
            [ STATEMENTBLOCK ] 
            [ ELSEPHRASE ] 
          'end if'

The difference is that Euphoria evaluates the expression that follows the 'if'
keyword in a manner that is not expected by nearly everyone else except Robert.
Taking your example code, this is what happens...

  if Correct = 'y' or Correct = 'Y' then

Let's assume that the user entered "Y" into the variable Correct. Euphoria will
first evaluate

     "Y" = 'y'

which is a sequence operation, meaning for each element in the sequence it will
apply the  " = 'y' " fragment. Remember that strings are sequences so the value
in Correct is equivalent to

  {'Y'}

so the result of this first sequence operation is 
  {'Y'} = 'y'   ===>  {0}
because the operation compares each element in Correct with 'y' and replaces the
result with either 1 or 0 depending on the comparision result. 1 means true and 0
means false.

The second sequence operation is 

   Correct = 'Y'

which is the same as 

   {'Y'} = 'Y'

which results in {1}

The final sequence operation is then
   {0} or {1}
which results in {1}

The net result of this is that your IF statement is equivalent to 

   if {1} then

but this is wrong as Euphoria requires the expression to result in an atom value
and not a sequence. This is why Euphoria doesn't like things like

  if "yes" then

But back to most other languages...

  if Correct = 'y' or Correct = 'Y' then

they would evaluate the expression as a comparision instead.

   Correct = 'y'  ===> false
   Correct = 'Y'  ===> true
   false or true  ===> true

and thus your statement is equivalent to

   if true then

which makes a lot more common sense than Robert's concept of an IF statement.


However, as Robert's philosophy on this is never going to change, 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.

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

6. Re: Another Error

• Posted by Chris Bensler <bensler at nt.net> Feb 01, 2007
• 692 views

Derek Parnell wrote:
> 
> Euphoria defines the IF statement as 
> 
>    IF ::  'if' ATOMEXPRESSION 'then' 
>             [ STATEMENTBLOCK ] 
>             [ ELSEPHRASE ] 
>           'end if'
> 
> but most other languages define it as 
> 
>    IF ::  'if' COMPARISIONEXPRESSION 'then' 
>             [ STATEMENTBLOCK ] 
>             [ ELSEPHRASE ] 
>           'end if'

Most languages, including Euphoria define an if construct as
IF::  'if' BOOLEANEXPRESSION 'then'
        [STATEMENTBLOCK]
        [ELSEBLOCK]
      'end if'

Your beef is with how Eu deals with relational expressions. Not conditional
expressions.
The fact that ("Y" = 'y') != TRUE has nothing to do with conditionals.
I used to think that Eu's vector operations were nifty, but I've been realizing
that it's nothing more than code reduction and convenience (maybe more of an
inconvenience). However you are arguing the wrong point. It just happens that the
problem with relational expressions surfaces most within conditional expressions.

I only mention this because I know your desire to change how relationals work
within conditionals and I don't entirely disagree, but I do disagree that we
should create some exceptional behaviour specifically for conditions. Vector
operations should probably be eliminated entirely in favour of a more universal
boolean evaluation.

> The difference is that Euphoria evaluates the expression that follows the 'if'
> keyword in a manner that is not expected by nearly everyone else except
> Robert.

I expect it to work the way it does. Knowing the mechanics of the language it
makes sense, but I agree that it's unintuitive.

Even if we could evaluate a boolean result with sequence relations, we would
still be using equal() and find() etc in alot of cases where we would deal with a
sequence in the expression.

Personally, I don't really care either way, but I think it would probably be
just as confusing. The advantage would be almost purely aesthetic.


Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

8. Re: Another Error

• Posted by "Greg Haberek" <ghaberek at gmail.com> Feb 01, 2007
• 699 views

I see nothing wrong with the current if statement.

On 1/31/07, Jason Gade <guest at rapideuphoria.com> wrote:
>
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> Rob, I understand your response but I agree more with Derek.
>
> I think almost all other scripting languages that Euphoria competes with work
> the way he describes. I believe that Pascal works that way (but I'm not sure...
> maybe not).
>
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
>
>
>
>

10. Re: Another Error

• Posted by Derek Parnell <ddparnell at bigpond.com> Feb 01, 2007
• 679 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

12. Re: Another Error

• Posted by Igor Kachan <kinz at peterlink.ru> Feb 01, 2007
• 690 views

Rich Klender wrote:

> 
> Well, I hit another snag, if anyone would be gracious enough to help!!!
> 
> Here's the code:
> 
> function AddFactions(integer C)
> 
>     sequence FactionName, FactionPassword, Correct
>     integer ReturnCode
> 
>     while C do
> 
>         FactionName = prompt_string("Input the name of the new Faction\n")
>         
>         FactionPassword = prompt_string("Input the Factions password\n")
> 
>         puts(1, "\n")
>         puts(1, "The Faction name is: ")
>         puts(1, FactionName)
>         puts(1, "\nThe Password is: ")
>         puts(1, FactionPassword)
>         puts(1, "\n")
>         Correct = prompt_string("Is this correct? y/n")
> 
>         if Correct = 'y' or Correct = 'Y' then
>             return ReturnCode = 1   
>         end if
> 
>     end while
> 
> end function
> 
> The problem is in the last if/then statement, if the user inputs 'y' then it
> returns to the main program, if not I want it to fall thru and the user
> re-inputs
> the correct data.  I get the following error:
> 
> H:\test1.ex:24 in function AddFactions() 
> true/false condition must be an ATOM 
>     C = 1
>     FactionName = "asdf"
>     FactionPassword = "asdf"
>     Correct = "n"
>     ReturnCode = <no value>
> 
> ... called from H:\test1.ex:62 
> 
> I know I'm missing something easy here...sorry I'll get the hang of this yet!!
> 
> Thanks!
> Rich

Hi Rich,

Yes, that *error message* itself is not as clear
as it could be:

"true/false condition must be an ATOM"

What is it ?

Your real mistake is just *comparing* an ATOM aginst a
SEQUENCE with the '=' operator, which acts for atoms only.
The 'Correct' variable is a sequence, 'y' and 'Y' are the
atoms, but for objects (atoms & sequences) we have two
special functions - compare() and equal(), not the '=' operator.

Read please once more that *error message*, it seems to me that
thing about comparing is just clear, but the message about
mistake is something cryptic and requires to be changed or
better explained in docs, at least.

The EU docs haven't a full list of the error and warning
messages of interpreter, binder and translator with their
explanations. It may be just one of the future steps in
development of Euphoria.

Just my $0.02.

Regards,
Igor Kachan
kinz at peterlink.ru

14. Re: Another Error

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 01, 2007
• 680 views

Derek Parnell wrote:
> 
> don cole wrote:
> > Back to the origtinal question
> > true/false condition must be an ATOM 
> >  if Correct = 'y' or Correct = 'Y' then(line24)
> > sequence FactionName, FactionPassword, Correct
> > 
> > Correct here is definately not an atom but a sequence.
> 
> Agreed, but the statement in question is not
> 
>   if Correct then
> 
> also the expression 'equal(Correct, "Y")' is also not an atom but it works
> because
> it is evaluated and returns an atom.
> 
> My problem is that 
> 
>    Correct = "Y" 
> 
> evaluates to a sequence rather than to an atom, in the context of an IF
> statement.
> If the rules were changed so that it did what it looks like its trying to do,
> no existing code would be broken and future code would be easier to write and
> read.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

Then let's just solve the problem.

When you perform string comparison, you, the coder, know that you are doing 
so, and the semantics of this operation won't likely change often. And it
is desirable that ayone reading the code understands it at first sight.

So, if you don't like

if compare(you,me) then -- ...

to test whether you and me are different sequences, perhaps would it help to
be able to write

if_sequence you != me then -- ...

This is just syntactic sugar. It would toggle a flag that tells rexpr() to
map relational operators to relations with compare() results. Otherwise, 
it would behave exactly like an ordinary if statement. You'd need an
elsif_sequence too, and the two brands could be freely interleaved.
Perhaps allow end if_sequence, but it would be an exact equivalent of end if.

I don't come fom Basic (haven't used it for 25 years), but from Pascal, which,
like Basic, knows about string comparison, since it knows about strings. Yet 
I think the current way of doing things is more intuitive and consistent:
extend atomic operaions to sequences, and use specific methods to deal with 
sequences as atomic objects. Perhaps my being familiar with the 6-letter 
word oriented programming ways (gotta be careful on this list).

But if if_sequence, or whatever you call it, is supposed to alleviate some 
newbie confusion, it would be easy to tuck it in the front end.

One thing which I find missing in Eu is the ability to perform element wise 
operations that might apply to sequences as a whole. I'd like to 
be able to write 

s=atom(`x)

(or anything just as little obstrusive), in order to get a sequence of true 
and false values which tell which, if any, of the elements of the sequence 
x are atoms. Of course, you can do this

function has_atoms(sequence s)
object x    
for i=1 to length(s) do
        x=s[i]
        s[i]=atom(x)
    end for
    return s
end function

and use s=has_atoms(x). Fine, you have to define one such helper finction 
for each function you'd like to use in this way. A real pain. In a nutshell,
functional operators are missing.

CChris

16. Re: Another Error

• Posted by Rich Klender <rklender at excite.com> Feb 01, 2007
• 663 views

See, this right here is what I love about Euphoria!!  You guys are great at
helping!!  Thanks for all the input, it really is educational and helps
with understanding the underlying logic.

Thanks!
Rich

p.s. You know, I'll by the time I get this program written I'll probably need
a seperate file just for all the thank yous and credits!! ;)