OpenEuphoria

Re: math.e and misc.e

• Posted by Derek Parnell <ddparnell at bigpo?d.?om> Aug 06, 2007
• 479 views

Robert Craig wrote:
 
> The idea of adding a special "NIL" value to the language,
> that is fully supported across all operations, is simply
> not going to fly.

I totally agree with this, Robert.
 
> The only thing that ever crossed my mind, as possible,
> though I would definitely vote against it, would be a 
> special function that would tell you if a variable 
> had been initialized yet. This would be easy to add to the
> Interpreter, but rather more difficult in the Translator,
> since the Translator does not currently test for 
> uninitialized variables, or worry about setting variables 
> to some magic value. The fact that some variables 
> might sometimes have this magic value, might complicate 
> translated code, where it sometimes sets things to zero
> for convenience regarding Refs and DeRefs, as one example. 

I understand your predicament. 

In the interpreter, changing 'object()' to return false for uninitialized values
would be useful for me. However, if the translator does not set values to an
uninitialzied state then it would be a bad idea.

One way out of this problem would be to actually initialize all values to a
defined state in both the interpreter and the translator. This is the way that
the D programming language does it and it works very well.

The idea goes something like, more bugs are caused by using uninitialized
identifiers (i.e. forgetting to set them to something) than setting them to the
wrong values. Even setting say atoms/integers to zero initially is beneficially
because this is the most common thing that coders do anyway.

So I propose that integers and atoms are set to 0, sequences are set to {}, and
objects are set to integer:zero, by the system before application code is run.
 
> And what are you going to do if you detect that a variable 
> hasn't been initialized? In most cases I suspect you'll 
> either initialize it to some default, or report an error. So what? 

So, its a good idea. I'm think specifically of how to write generic routines
that can allow 'default' parameters to be passed. For example...

   function Foo(integer A, integer B)
      -- Check if B needs the default value.
      if not object(B) then
          B = 17
      end if
      . . .
   end function

   . . .
   Foo(3) -- Uses defaulted second parameter.

I'm NOT advocating this for the language (yet) but just giving one of many
examples where runtime knowledge of the state of variables could be useful.

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