On Jun 25, 2006, at 16:16, Dark Ambient wrote: > If I'm assimilating this correctly then if something is not equating > to false then it automatically equates to true. Which makes sense. > However, sadly I must say setting up the loop is still a problem for > me to grasp. (Maybe I should consider another hobby :)) Basically, only 'nil' and 'false' are false in boolean expressions, everything else is true. 'nil' doesn't equate to 'false', however: nil == false # => false I tried the code and don't get an error on it - maybe it's a version problem? In any case, the standard syntax of a case statement should work for all versions, it generally looks like this: case var when 'something' puts "hello world" when 'another thing' ... else # code for all other cases end Read up on it - Ruby's case statement is enormously flexible. As for the loop, what you need to ask yourself is "what are the conditions where the loop should terminate?" and remember that those conditions are evaluated only at the start of the loop (for while- loops). So, for your case: loop condition: not reply | stops? | *should* stop? possible values of | true | yes | yes reply at the start | false | no | yes of the loop | (str) | yes | no Where (str) is the user's input. It's pretty obvious that checking the truth-value of reply isn't going to work as a loop condition in this case. Basically, you need to think up another condition for your loop, one that is only true when you want the loop to perform another iteration, and is only false when you want the loop to stop. The simplest way would be to create a variable specifically to track the loop's state: continue = true while (continue) reply = gets.chomp.downcase case reply when 'yes' continue = false reply = true when 'no' continue = false reply = false else puts 'only "yes" or "no"' end end I'll point out that this isn't a very elegant solution, though it has one major advantage: it makes the behaviour of the loop absolutely explicit and understandable. It's extremely difficult to come up with the compact and elegant solutions without understanding the basic ones like this. best of luck, matthew smillie.