OpenEuphoria

RE: Uninitialized Variables

• Posted by Chris Bensler <bensler at mail.com> Mar 23, 2002
• 430 views

Refer to my includeed original message, paragraph 4 :P.

It is useful nonetheless.
No, you can't use it in 3rd-party libs, because it's a manual 
convention. And no, you can't use it in cases where you are dealing with 
extremeley large numbers.

The factor that it's a manual effeort is a nuisance, but worst case, you 
run your program, and it tells you that's it's uninitialized (heh, 
oxymoron).


I know it's not the solution, but I have stumbled on this case before, 
and my method would have worked just fine.


Chris


Derek Parnell wrote:
> ----- Original Message -----
> From: "Chris Bensler" <bensler at mail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, March 24, 2002 8:00 AM
> Subject: RE: Uninitialized Variables
> 
> 
> >
> > Sorry Bernie you misunderstood. This is a way AROUND that limitation.
> > The best that I can think of.
> >
> >  The circumstances are fairly limited to when it would be useful to know
> > if a variable has been initialized yet. In those cases, I'm suggesting
> > that you could just initialize it to -INF for atoms and integers, and
> > INF for sequences and objects. Yes, there are cases where this wouldn't
> > work, but they would be extremely rare.
> >
> > Your program would then consider variables that contain -INF or INF are
> > uninitialized.
> >
> > I know it's not the optimal solution but it's better than none.
> >
> > It would be next to optimal if NAN had a unique value. Then we could
> > have a unique identifier for each uninitialized variable. I don't know
> > the nature of NAN though, so I assume it's supposed to be equal to
> > everything.
> >
> 
> A nice try. But it has at least three remaining problems:
> 
>   a) It is a manual effort. So if you forget to do it, something will fail
> somewhere.
> 
>   b) It can't be relied on for use inside 3rd-party library files. IOW, if 
>   I
> write a library routine that includes a function written like:
> 
>       global function xx(sequence s)
>            -- check for uninitialized parameter.
>            if equal(s,INF) then
>               s = ""
>            end if
>            . . .
>       end function
> 
> and this library is included by somebody in their program, I cannot rely 
> on
> them using the INF convention. And likewise, if I use a somebody else's
> library function, I can't rely on them testing for uninitialized values 
> in
> this manner.
> 
>   c) Unfortunatly, INF is a valid value in its own right, and can be used 
>   in
> situations other than checking for uninitialized variables.
> 
> The problem really needs to be addressed inside the core Eu interpreter. 
> It
> knows if a variable is truely initialized or not. The changes are 
> simple.
>    - Allow uninitialized variables to be passed as parameters.
>    - Create a built-in way of testing a variable's initialization state.
> 
> and possibly
> 
>    - Create a built-in way of setting a variable's state back to
> uninitialized.
> 
> This will not break any existing code, and will enable people to write 
> more
> robust code.
> 
> ------------
> Derek.
> 
> 
>