Doug Edmunds wrote:
> I ran the example from the documentation
> for graphics:
> g = new graphics.
>
> However in the units.txt datafile,
> g is used for the gram units.
>
> Is there some way to revert / reset
> a variable (in this case, g)
> to the default unit setting,
> without closing and reopening the program?

Doug,

Unfortunately, no, at this point, there is no way to undefine a local
variable. If it goes out of scope (e.g. when you exit the function in
which it's defined,) then it will be undefined after that point.
However, this doesn't help you in the interactive mode, where you're
already at the top level.

> I see that I can do this manually:
> g = gram
> But if the default isn't known
> or is long (like R =
> 8.314472 m^2 s^-2 kg K^-1 mol^-1 (molar_heat_capacity)
> ), that's not so easy.

Agreed. And even if you know the original definition so that you can
reassign it manually like this, a local variable doesn't work *quite*
the same as a unit definition. For example, local variables are not
checked for prefix/plural rules.

Ah! That gives an idea for a workaround, although it's not pretty.
It's based on the fact that only defined units (defined with the :=
operator, as opposed to local variables defined with the = operator or
"var" keyword or the like) are checked for prefix/ and pluralization
matches. (That is, so you can define "gram" and "grams" or "milligram"
or "kilograms" will automatically work.)

Thus, if you've "shadowed" the unit "g" with a local variable, you
can define a new prefix with the :- or ::- operators that define
prefixes (the difference is that the latter also lets you use the prefix
as a stand-alone unit name.) If this prefix is defined to have the
value 1, then you'll get the original unit out. For example,

unit_ :- 1

then, using the "unit_" prefix, you'll get the original unit:

unit_g

returns the original value of the gram.

This is a good enough idea that I've added that prefix to the
standard units file, so you don't have to define it again. If you
download the latest version of Frink, you'll get this behavior.

> Is there some way to warn that a variable
> is already assigned, so it isn't accidentally
> changed (like g from grams to a graphics object)?

Currently, no. There are a rather large number (3396, not counting
prefixes and suffixes) of unit names defined, and the number of warnings
would be rather high. Doing that checking would have a runtime cost
every time a new variable was created, and that can be high in tight
loops. (Prefix and suffix checking can get expensive.)

I've considered making some facility that tells a variable to
undefine itself. There are a few issues with this, though. Note that
the rest of this becomes rather technical, so you can quit reading if
you're not interested in the reasons *why* it's not often good to be
able to undefine a variable.

1.) If you're writing a program, this is not a large issue. Just
modify the variable name and run the program again. So I'm assuming
that the problem occurs while running an interactive session.

2.) Allowing a variable to undefine itself at runtime wreaks havoc
with any programming language's ability to analyze, at compile time,
whether a variable is defined and what it is bound to at any given
point. (For example, a variable may be undefined in one branch of an
"if" statement, but not in another.) This is not really an issue for
simple calculations in interactive mode, but it has very large
implications for the assumptions that a compiler/optimizer/static type
checker can make.

3.) While Frink currently doesn't do a lot of compile-time
typechecking of variables, I certainly want to introduce more of this
compile-time analysis in the future to help programs run faster, and to
catch more types of errors. At some point, there may be a switch to
force you to declare variables before you use them, and/or there may be
a separate switch to force you to state that an identifier refers to a
unit instead of a local variable.

4.) This point used to contain a technical description of the way
that variables are defined in Frink, and a kludge I could make to change
its behavior, and allow a variable to be "sorta undefined" but I was
unable to convince myself that it was a good idea, and deleted it.

5.) This can't be an ordinary function, because ordinary functions
can't affect the variables defined in the context of their caller.
It'll have to be something "special" like the eval[] special
(not-really-a-)function which operates in the context of its caller.

Because of 2.) above, there are strong reasons not to introduce any
ability to undefine a variable at run-time, as that facility would
seriously hamper many compiler optimizations and static analysis of
programs.

It's possible that I could allow it with a huge warning every time
it's invoked with a message that says something like "a local variable
has just been undefined. If you're doing this in a program, stop it.
This hampers the compiler's ability to perform optimizations and it's
not expecting this to happen. The behavior of a program that uses this
is undefined, and unpredictable, and all bets are off. It may be safe
to do this in interactive mode, but don't do it in a program you're
writing."

But even that warning understates the problems if used in a running
program, and it may have to be disallowed entirely.

There's a possibility that a bit of a kludge could be implemented to
undefine a variable essentially at "compile time", because an
interactive session is really a bunch of short compile-evaluate-print
stages. The "clearing" of the variable could be treated as something
that only happens at compile time, and would have no effect on a
program, because it's only evaluated immediately at compile time and
doesn't get written into the program. I'll think about this approach,
if the above "unit_x" workaround isn't satisfactory.

Alan Eliasen
eliasen@...