OpenEuphoria

Re: A question about certain language features

• Posted by Derek Parnell <ddparnell at bigpond.com> Feb 15, 2002
• 600 views

----- Original Message -----
From: "David Cuny" <euphoria_coder at HOTMAIL.COM>
To: "EUforum" <EUforum at topica.com>
Subject: Re: A question about certain language features


>
> 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.
>

Yes David, I think that approach sounds good too. In a related issue, I once
suggested that it would be useful to know at run-time whether or not a
variable has been initialised.

Something along the lines of:

   if not initialized(x) then
       x  = 0
   end if

------
Derek