At 12:02 PM +0200 on 6/20/99, M. Uli Kusterer wrote:
>>Yes, and it would allow a massive proliferation of constants.
>
>Anthony,
>
> Does this mean it would allow easily adding constants or do you mean this
>would weaken the status of constants? My dictionary isn't that
>comprehensible in its description of "proliferation".
It would allow for there to become a lot of constants. We would not need to
worry so much about compatability. Because, for example, someone used "e"
as a variable, and we made it a constant, their value in "e" would overide
the constant.
Of course, it would also weaken the value of constants -- because the could
be assigned to. pi does not mean much if pi can be any old number.
>
>>Yeh, but this requires running the parser multiple times and further
>>hacking the lexical analyzer.
>
> Yup. That's why the variable approach might be better here. I just hope
>this doesn't cause some strange bug which will have our users modifying the
>values of constants... Code even more carefully than usual, my trusty
>friend.
If we have predefined variables, users would be able to modify them. Pi
would not neccissarily mean � and e would not necissarily mean e -- and
neccissarily would not neccissarily mean neccissarily for that matter
(especially since I can't spell it!)
I'm worried that it would lead to the degradation of constants along with
the proliferation...
Another problem with constant variables is code that tests if a variable is
defined:
if "e"=e then
-- e is (probably) not defined
else
-- e is defined
end if
Of course, that code does not work (and will not be made to work) with
Interpreter. It's not possible to do with compilation. I'll provide a
seperate function to test for definededness.
