>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.
Yup, compatibility would be really better this way. Here I'd love to be
back with Velocity for a second -- since it didn't really tokenize it never
had a problem with variables vs. constants. If you put into something it
*had* to be a variable and constants were never checked, and variables were
checked first (before any constants). But for the speed penalty it isn't
worth it.
When I later realized I needed a tokenizer to speed up Velocity (I never
got around to implementing it, though) I got the idea of having every token
carry along the start and end of its representation in the original script
text. This way one could re-evaluate a token if it didn't make sense. Also,
one could've special-cased some tokens like "e" or "a" so they'd check for
a variable of that name first. But I think making them pre-initialized
local variables is much more effective and provides for much more general
code.
>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!)
What you need is latin. compatibilis, necessus, ... You don't need to get
the declinations right, just learn the words ;-)
>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.
>(...)
>I'm worried that it would lead to the degradation of constants along with
>the proliferation...
That's why we need them to be in the local variable scope. This way
they're reset at idle. I guess you already imagined what would happen if we
implemented them in the global scope to save memory. Ideally, these locals
would only be added if the token "e" is encountered once. BTW, doesn't "e"
stand for the name of its inventor? Maybe we could avoid the problem by
using the full name?
>Another problem with constant variables is code that tests if a variable is
>defined:
>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.
Well, I can't recall any place in HyperTalk where this would be used. Of
course, it's never bad to be able to test for definedness, and we can
always remove it to avoid bloatware (I'd propose "there is a variable",
"there is a global" etc. for the syntax, but this is xTalk business).
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
