1. Re: math.e and misc.e
- Posted by Derek Parnell <ddparnell at bigpo?d.?om> Aug 06, 2007
- 480 views
- Last edited Aug 07, 2007
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