# Different strategies to get a clean Kernel. Quit, Exit, ClearAll, Remove, CleanSlate?

Often new users face problems with lingering definitions that, if unaware, may cause unexpected and frustrating behaviour.

There are several answers that illustrate different aspects of the solution, but not a single place that can serve as a guide where the best strategies are compared side by side.

For example, in this answer @celtschk points to the need of using

ClearAll[Evaluate[$Context <> "*"]]  instead of ClearAll["Global*"]  in the cases when the Notebook has a Context set to "unique to this Notebook". This answer by @LeonidShifrin compares Remove versus ClearAll. In this other answer @Szabolcs gives an extensive explanation to the "significant practical differences" between Quit versus ClearAll["Global*"]. And here @C.E. points to the use of Needs["UtilitiesCleanSlate"] CleanSlate[]; ClearInOut[];  Ultimately the advice seems to come to actually closing the kernel and starting one fresh, either via Exit or Quit. Quit[]  But that doesn't cover preventive measures nor the possibility of a Dynamic cell in the notebook, or initialization commands or any other mechanism that could re-spawn definitions. Here I'm hoping for a canonical guide to the problem of a fresh kernel. 1. Prevention 2. New kernel 3. Cleaning (Still waiting for a canonical answer) ## 4 Answers # PREVENTION This is a Community Wiki answer that has not reached maturity yet. Experienced users are welcome to add to it and correct mistakes. Best practice is to avoid the need to clean the kernel at all, by avoiding the creation of lingering definitions that may later obscures the behavior of Mathematica. When you write a program in the Wolfram Language, you should always try to set it up so that its parts are as independent as possible. Some ways to avoid lingering definitions are: 1. Avoid creating variables 2. Use nameless pure functions 3. Scoping, keep variables local 4. Use ReplaceAll 5. Use long descriptive names ### 1. No variables Take full advantage of Functional Programming and nest or compose all or most of your operations. Do f[g[h[x]]]  Instead of a=h[x]; b=g[a]; c=f[b]; c  ### 2. Pure functions You can create functions without a name, using Function or its short form (#)&. Read about Pure Functions. Do Map[(2 # + 1) &, Range[4]]  Instead of f[n_] := 2 n + 1; Map[f, Range[4]]  ### 3. Scoping You can limit the scope where a variable is defined using Scoping Constructs, effectively creating local variables. Look at Module, Block, With. With[ {a = 3, b = 4}, a^2 + b^2 ]  ### 4. ReplaceAll If you need to evaluate your expression for a particular argument or parameter you can use ReplaceAll or its short form /. π r^2 /. r -> 3.656365 (* 42. *)  ### 5. Variable names The shorter and common-place is your variable name, the most likely is to collide with something else. Don't store your data in a variable called x and then complain that Plot[Sin[x],{x,0,1}] doesn't work. Use long names that start lowercase, to avoid using Symbols that have built-in meaning in Mathematica. # NEW KERNEL This is a Community Wiki answer that has not reached maturity yet. Experienced users are welcome to add to it and correct mistakes. To get a fresh kernel for the current notebook, one can either kill the current kernel and re-start it or associate and start a new different kernel. ### Killing current kernel Quit and Exit both terminates a Wolfram Language kernel session. Simply Quit[]  Alternately, one can select Evaluation > Quit Kernel > Local from the menu bar. If you have set up alternate kernels (see below), replace "Local" with that kernel's name instead. ### Configure alternative local kernels Sometimes killing the current kernel may not be desirable, and the best approach is to start a second kernel. If you don't have a second kernel already configured, then start by configuring a new kernel: Evaluation > Kernel configuration options > Add > OK or CurrentValue[$FrontEnd,
{EvaluatorNames, "Local2"}
] = {"AutoStartOnLaunch" -> False}


### Associate a new kernel to the notebook

Then, associate a different kernel to the current notebook:

Evaluation > Notebook's kernel > #kernel-name#

or

CurrentValue[
EvaluationNotebook[],
Evaluator
] = "Local2"


### Example

The animation shows the process to configure and associate a secondary local kernel.

The following may not be so useful in packages, but in open notebook evaluation the kernel can be repeatedly quit like so, using a tip from Arnoud Buzing.

In this case the orange cells evaluate repeatedly until b reaches 4. The value of a is lost on each quit.

Code text

ClearEvaluationQueueOnKernelQuit /. Options[$FrontEndSession] SetOptions[$FrontEndSession, "ClearEvaluationQueueOnKernelQuit" -> False]

Clear[a, b]

a = If[ValueQ[a], a + 1, 1];
b = If[ValueQ[b], b + 1, 1];
SetOptions[EvaluationNotebook[], TaggingRules -> {"b" -> b}]

Quit[]

b = CurrentValue[{TaggingRules, "b"}];
If[b < 4,
SelectionMove[nb = EvaluationNotebook[], Previous, Cell, 3];
FrontEndExecute[FrontEndToken[nb, "SelectNextLine"]];
FrontEndExecute[FrontEndToken[nb, "SelectNextLine"]];
SelectionEvaluate[nb],
{a, b}]


rhermans mentioned using long descriptive variable names. Those variable names are even less likely to collide with other variables if they are a regular characters mixed with Script, Gothic and DoubleStruck characters. For example:

This approach is used in the source code of the Notation` package. Also keep in mind that the full name of built-in symbols always starts with a capital letter. If your variable starts with a capital letter and doesn't use Script, Gothic or DoubleStruck characters, it may be a built-in symbol in a future Mathematica release.