1. Re: math.e and misc.e
Robert Craig wrote:
>
> Juergen Luethje wrote:
> > Robert Craig wrote:
> > > Note that there is already a bit pattern that means "NO VALUE".
> > > That's how the back-end detects uninitialized variables at run-time.
> > > However I'm reluctant to make it a visible part of the language.
> > > It might constrain future optimizations, features etc.
> >
> > Out of curiosity:
> > Maybe you could give an example of such optimizations or features,
> > which might be constrained by making that bit pattern a visible part
> > of the language?
>
> The idea of adding a special "NIL" value to the language,
> that is fully supported across all operations, is simply
> not going to fly. Who would want to greatly slow down all operations,
> and make both the backend and the translator much more
> complicated than they already are, just so they
> can have a specially blessed "NIL", rather than simply
> specifying in their particular program:
> constant NIL = -1
> or whatever, as the case may be?
>
> e.g. internally you'd see C code like this everywhere:
>
> if (a == NIL || B == NIL) {
> result = NIL;
> }
> else {
> result = A + B;
> }
>
> and sprinkled all through the Translator and translated code
> as well.
>
Adding a special value wasn't what I had in mind, for exactly the reason you
mentioned.
Instead, I was considering adding a new tested for bit pattern, and the tests
for NIL would always come as the last thng being done. This way:
* 1-op are easy: treat NIL as a fallback case.
* INT-INT operands are still treated separately, and the NIL test isn't seen;
* A NIL in the first operand would be tested last, so that again, usually the
test wouldn't be performed at all;
* A NIL in the second operand may or may not need to be tested before regular
values.
The basic idea is: the C code will be peppered with many NIL tests, but they
will be executed seldom. And it is not illogical to consider that NIL values are
processed a little more slowly than others. Since the action taken on NIL input
is often almost nil itself, the penalty of taking all tests and failing them on a
NIL input may not be that high.
Reordering of tests will have to be carefully checked of course. And this
assumes there is an efficient way to filter off NIL items in useful/earlier/more
frequent type tests. If there is none, then the point above is moot, and we'll
have a "can't be implemented without a meaningful loss of performance" advisory
somewhere. And because there will be precise documentation on why it cannot be
done efficiently, this will cut down on the amount of discussion later, when the
topic surfaces again.
> Who wants to pay the performance cost?
> Who wants to ensure that these checks are religiously
> performed now, and in all future additions to the language,
> everywhere in the code? Would any future developer ever
> forget to check for NIL? Of course he would.
>
The point of NIL is that, if you don't check it, it will propagate in a way
diffrnt of any other program data flow, and the result of execution will be nil
or NIL, depending on the exact state and expected output. It is much safer to
have NIL than to:
* rely on a global status variable (say _errno), which you'll forget to check
and which may be internally clobbered (some instances of this in the Windows
API);
* use special values for invalid/undefined output - what we are all doing right
now - because these marker values may propagate in sneaky ways if we forget to
check. And of course we do.
> 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.
>
> However, just because something is relatively easy to do,
> and possibly of use to someone, somewhere, in some program,
> does not, of course, mean it should be done. I feel the
> concept of an uninitialized variable should remain a kind of
> "meta" concept, not something that can be inspected and
> manipulated by a program at run-time. I think it should
> remain the implementation's business, exactly how this is detected.
> Not something that can become the subject of an algorithm.
> This unnecessary feature would add a bit of complication
> to everyone's understanding of the language.
>
> 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?
>
As long as the source code is static, and cannot change from the point it is
loaded on, I certainly with the feature not being useful.
However, is this behaviour, very uncharacteristic of interpreted languages, to
stay forever? Think of EuMirc by Kat. But all right, it means that checking for
uninitialised variables is _currently_ mostly useless.
CChris
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
