Re: Options and FilterOptions
- To: mathgroup at christensen.cybernetics.net
- Subject: [mg989] Re: Options and FilterOptions
- From: villegas (Robert Villegas)
- Date: Thu, 4 May 1995 08:14:46 -0400
- Organization: Wolfram Research, Inc.
wagner at bullwinkle.cs.Colorado.EDU (Dave Wagner) writes:
> Thanks for pointing out that options could be specified as delayed
> rules; I never would have thought of that. In truth, I still can't
> think of a case in which you'd want to specify an option that way *in a
> function call* --- that is, I can see why one sometimes needs delayed
> rules in Options[foo], but not in foo[___, opts].
One option that needs an unevaluated option setting is the DialogSymbols
option of Dialog.
In[14]:= ? DialogSymbols
DialogSymbols is an option for Dialog which gives a list of symbols whose
values should be localized in the dialog. DialogSymbols :> {x, y, ... }
specifies that x, y, ... should have local values for the duration of
the
dialog. DialogSymbols :> {x = x0, y = y0, ... } defines initial values
for
variables.
Most likely, you expect some (or all) of the symbols you list to have
global values, and you want to tuck those away for the duration of the
dialog so that your digression will have a clean slate (as far as those
variables go).
Right now, I can't think of another option of a system function
that needs the :> so definitely in the function call itself, but
I might be forgetting some. However, in general, especially when
you get to user-defined functions, there are several conceivable uses
of an unevaluated option setting:
(1) If the setting of an option is some symbolic expression, you might
want to keep it unchanged by global values. For instance, you might
want x^2 + y^2 to stay x^2 + y^2, not be pre-evaluated using the
assignments you just made a few lines back: x = 749 and y = 175.
Or maybe the expression is a structure the program will dissect or look
for, say 2^10 5^30, and it needs to stay intact.
(2) The option might be one that is used only after most of the command
is over, so the running of the command itself might be needed to determine
the value of the option. It might be that the running of the command
changes the value of some variable, or affects the state of Mathematica
in other ways that the option setting makes reference to (perhaps very
indirectly: SessionTime[] or MemoryInUse[] would be different after a
command has run).
This might be a contrived example, but someone might have actual
applications that use the same idea:
p = 0;
Plot[(p++; Sin[x]), {x, 0, Pi}, PlotLabel :>
StringForm["`1` samples were generated during this plot", p] ]
(3) The option might be one that is supposed to be set to some little
procedure you want executed at key points during the main program.
Maybe the main program loops, and you want to be able to specify a little
cleanup procedure that is done between passes through the loop (Todd
Gayley mentioned he was using this in one of his functions once, although
I forgot the context). Something like
f[expr, RunThisBetweenSteps :> Module[{a, b}, whatever] ]
This list isn't exhaustive and the items really overlap, but I think
it's a useful classification of some different uses you might make for
opt :> value.
So in general, it would be good to anticipate the RuleDelayed possibility,
even if it's used only occasionally for more specialized things.
Robby Villegas