OpenEuphoria

Re: A question about certain language features

• Posted by David Cuny <euphoria_coder at HOTMAIL.COM> Feb 15, 2002
• 579 views

Karl wrote:

>An argument could be made that uninitialized variables ought to be 
>prohibited.

I thought about that when I was writing this. One problem with this is that 
some variables are placeholders, and don't have a default value. For 
example:

   integer key

   while (1)
      key = wait_key()
      if key = <some value> then
         exit while
      end if
   end while

Another is that just because you set a variable to a value doesn't mean that 
it's a *sensible* value, or that it will make the code behave properly. 
After all, you could initialize a flag to TRUE, when the default should have 
been FALSE.

In retrospect, I have to admit that allowing initialization at declaration, 
while increasing the chances that a variable will be initialized, doesn't 
*guarantee* that it will. So it's not entirely a good solution for the 
problem that I'm trying to solve.

I think Java got it right in some ways, complaining in cases where a 
variable is used where it might not be initialized. For example:

   integer i
   if rand(1) then
      i = 1
   end if
   return i

would fail in Java, because it would recognize that "i" *might* not be 
initialized. But it's just fine in Euphoria. Mind you, that was sometimes a 
pain - I'd have to add 'else' clauses that I was sure wouldn't execute just 
to make the compiler happy. But it would certainly solve the problem.

Euphoria does check to make sure that "i" is actually set to some value 
somewhere in the routine. If you wrote:

   integer i, j
   if rand(1) then
      i = 1
   end if

you'll get a warning that "j" is not used.

So, while I'd prefer to be able to assign variables at runtime, a better 
solution fot the problem would be to make the interpreter smarter, instead 
of extending the language.