In this question: Options which require RuleDelayed , an example was given, where the an option has to be given as a RuleDelayed: EvaluationMonitor of NMinimize.

But many other functions use Functions in the same application: take ColorFunction of DensityPlot.

Instead of usage

NMinimize[x^4 - 3 x^2 - x, x, EvaluationMonitor :> Print[x]]

one could perhaps implemented NMinimize as

NMinimize[exp_, x_, ___, OptionsPattern[]] := 

Another example in an answer was Path :> $Path which delays the evaluation, but in many applications Automatic is used instead, which then triggers evaluation.

In which applications are RuleDelayed useful for giving options? Are there applications, where the lhs of the option would be a pattern?

I would like to understand the design pattern and good practice behind these advanced features.


Short answer is, you can achieve the same with different idioms but some are better in some cases than another. Pick the one that reduces amount of code that you and user need to write because it will probably contribute to experience and robustness.

Options which expect functions

ColorFunction, MeshFunctions etc all are supposed to be functions because the author provides a fixed set of arguments and it is up to the user what to do with them.

Options with :>

Why not a function for EvaluationMonitor? Because, among others, NMinimize can have many different things in its varspec. It can be a symbol, list of symbols, _ ∈ region_, etc.

Either user would have to have parse it MonitorFunction -> myMonitor @* standardizeVarspec or the author would have to waste time to convert any varsepc to e.g. a list of symbols. Not worth the effort if user can just write Print[x].

Options with :> vs symbolic options

The gain in Path :> $Path case, except it obviously delays $Path evaluation, is that the author does not need to write OptionValue[Path] /. Automatic -> $Path etc. Not the major problem but that line can be half of its length. Additionally it is self documenting.

It may be worth it, if the default value ($Path) is simple and there is only one default value (for more you need to switch inside anyway).

If it is not simple it may be a pain to use when user writes a code that plays with that option. This is fine:

path = If[condition, customPath, $Path];
YourFunction[..., Path -> path]

This is not:

opt = If[condition, customOpt, complexValueOf[YourFunction's, Default->Option] (*made up example*) ];
YourFunction[..., Opt -> opt]

So here a symbolic options make more sense:

opt = If[condition, customOpt, Automatic ];
YourFunction[..., Opt -> opt]
|improve this answer|||||
  • $\begingroup$ Thanks for a great answer! You covered almost all of my concerns. How about left side value being a pattern? Does option like Options[myfunc]={f[a_]:>g[a]} have any application examples? It feels very powerful. $\endgroup$ – Johu Sep 18 '18 at 10:24
  • $\begingroup$ @Johu I am not sure how should that work, how would e.g. a call to myfunc look like? And how and what would you like to retrieve the option inside? What pros do you see here? $\endgroup$ – Kuba Sep 18 '18 at 11:34
  • $\begingroup$ This was my question :). $\endgroup$ – Johu Sep 18 '18 at 12:33
  • $\begingroup$ @Johu I understood your question as 'where is this feature useful' while I am asking, but what feature? Options[myfunc]={f[a_]:>g[a]} is not enough for me to understand what do you mean.\ $\endgroup$ – Kuba Sep 18 '18 at 12:36
  • $\begingroup$ ok. thanks. I will add an extend example to the Q later. $\endgroup$ – Johu Sep 18 '18 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.