4.6  •  5.0  •  5.1  •  5.2  •  5.3  •  5.4  •  6.0  •  6.1  •  6.2  •  6.3  •  6.4  •  6.5


Evaluates a typescript command. Returns the typescript output as a string.

There are some dangerous aspects to this function. It is not a function most users will want to make use of. However, because it provides access to typescript from expressions, it does open up some doors, making something things possible that would not otherwise be. But, if you use EvaluateScript, Analytica does not prevent you from "shooting yourself in the foot".

Despite the warning, there are many legitimate uses.


The following creates a list of all keywords in Analytica:

Index kw:= Split(EvaluateScript("Command List|list]] keyword")," ");

Error Handling

When an error occurs while processing the typescript, the error message is returned in the text of the result. In Analytica 4.2 and later, the optional «showErr» parameter can be specified as true to halt execution and display the error:

EvaluateScript("show nothing") → "Syntax error at line 1: Undefined name."
EvaluateScript("show nothing", showError: true) → { Evaluation stops, error dialog appears }

When «showError» is true, the error can also be caught using the Try(..) function. (Analytica 4.6 or later).


EvaluateScript makes it possible to go around Analytica's referential transparency rule that prohibits side-effects while a variable is being evaluated. If you choose to do so, you do so at your own risk. In particular, unpredictable things may occur, including the potential for a crash, or for incorrect computations, if you alter something that a pending computation depends on. For example, if X is in the process of being computed, and A is upstream from X. If you use EvaluateScript to change A, which you might do from some variable far removed from X, the computation of X may experience serious problems. Since it is in the process of being evaluated, it may have already computed intermediate results that are no longer valid given the change in A. It won't know this, and will plow ahead with the remainder of the computation, possibly producing a nonsense answer, and possibly even crashing.

One situation that is particularly nefarious is the case where a Dynamic evaluation is in progress. A dynamic evaluation bases its computation of the model's global loop structure. Previously computed information on the model's loop structure is invalidated when a definition in the model changes. Hence, you should never use EvaluateScript to alter a variable's definition if there is a possibility that a variable in a dynamic loop is in the process of being evaluated. This case if extremely hard to debug to figure out what is happening, and the symptom may simply be that numeric results aren't correct.

Another mistake to avoid is assigning to RandomSeed while a variable evaluation is in-progress, since this causes all uncertain quantities to be invalidated. You can assign to RandomSeed using the Assignment Operator :=, even when a computation is in progress, so if you want a "deterministic pseudo-random sample" use assignment, not EvaluateScript, e.g., from an expression, RandomSeed:=5; Uniform(0,1).

With EvaluateScript, you are given the ability to shoot yourself in the foot, but in rare cases, the fact that it is not limited can make it possible to work around core limitations.

In general, side-effects created by EvaluateScript are not particularly dangerous from UDFs called from button scripts, OnClick or OnChange handlers.

See Also


You are not allowed to post comments.