The discussion about definable constants (or not) reminds me of the
similar situation in Pepper. I intend Pepper to be used interactively,
in the same way as Pop, and yet wish to avoid some of the strange effects
(such as redefinable constants).
The Pepper solution is this. First, there are two kinds of declarations,
``val'' and ``var''. Identifiers declared by ``val'' are not assignable
(the declaration initialises them), while those declared by ``val'' are.
[Quickly scanning the Pepper code to hand, I see more than 750 ``val''s
and less than 250 ``var''s. These figures are distored in favour of
``var'' (yes, in *favour* of *vaR*) because (a) var's tend to appear
at top level, (b) there are two very similar large programs in my
sample, which both (c) use var's to cope with the bootstrap compilers
inability to have top-level val declarations with run-time initialisation
values.]
Names are redefinable (``fluid'') or not (``static''; these terms are
not fixed, not least because the compiler doesn't do this yet!).
Redefinable constants (val's) are just like variables, except for being
unassignable; that is, when they are redefined, everyone sees the new
value (unlike Pop constants). Unredefinable constants get their values
compiled into the code.
Qualifiers on declarations allow the programmer to choose between
re- and unre- definable. The default in interactive use is re-; for
batch compilation, it is unre-. (Just as well, because the bootstrap
compiler doesn't allow any sort of redefinition.)
Thus you can never over-ride a static val's value, and a fluid val's
value is subject to change without notice. There will be a way to
pick the default qualifier, so you can make an interactive compilation
get you static val's. The effect of Pop's ``protected'' will probably
be obtained by the as-yet-vague module system.
--
Regards | "Always code as if the guy who ends up maintaining your code will be
Kers. | a violent psychopath who knows where you live." - John F. Woods
|