1. Re: math.e and misc.e
Derek Parnell wrote:
> 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.
Not if the use of an uninitialized variable is always caught
by the interpreter.
> Even setting say atoms/integers to zero initially is beneficially because this
> is the most common thing that coders do anyway.
That just increases the chance that the program will run without
obvious error, and do something, or output something that is
subtly wrong.
> 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.
No thanks.
If I forget to initialize a variable, I'd rather be told about it
immediately, than have the system quietly "guess" what the
correct value should be.
Furthermore, you aren't doing me any favors by picking a
common default value like 0 or {}. That just increases the chance that
my program will appear to run fine. I'd just as soon
have you pick -135783.88, which is more likely to force an error,
and clearly show me that my program is wrong.
Catching all uses of uninitialized variables is obviously
the gold standard here. Any other solutions are for languages
that can't or won't do that.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
