I will interpret your question in the narrow context of customizibility. Most of the information can be found in the documentation, but is alas scattered over several places. Below I will attempt to assemble a single sequence, mostly using this source. Where my description deviates from it, I will put the LS sign indicating that what follows ismy interpretation. Also, I have to make a disclaimer that some parts of this I haven't tested thoroughly enough to be fully sure that I am 100 percent correct, so I invite anyone to edit this if some mistakes are found.
With that out of the way, here is what I believe is a reasonably accurate description of what happens when you press SHIFT+ENTER to evaluate a cell in the FrontEnd session:
CellProlog, if defined for a given cell (LS:
CellProlog is an option for the cell which defines a piece of code to evaluate, not a function of the input).
CellEvaluationFunction, if defined for a given cell
- In a
CellEvaluationFunction is applied to the
BoxData expression representing the input to be evaluated.
- In an
InputForm cell, it is applied to the string corresponding to the input to be evaluated.
LS: In all cases, this is a function which is applied to the input (string or boxes). At this point, one can divert the entire evaluation loop as one wants, including evaluations not involving Mathematica kernel at all (e.g. code in other languages, processed externally. See this excellent answer by WReach for the exposition of the possibilities this offers).
All the steps below assume the default CellEvaluationFunction, which is Identity
Read in input (LS: in a string or boxes form, presumably depends on the cell type).
$PreRead function, if defined, to the input string (LS: also for a box expression if an input is read as boxes. Note that if
CellEvaluationFunction has been defined and still calls the kernel to evaluate the result, then
$PreRead is applied to the result of
Print syntax warnings if necessary.
$SyntaxHandler function if there is a syntax error.
MakeExpression to create an expression from boxes
LS: As a part of expression creation, call
$NewSymbol on every new symbol to be created, then create that symbol. The choice of context where the symbol is created is based on the current (at the time of symbol's creation) values of
$ContextPath. Obviously, cell and notebook contexts, when enabled, must be communicated to the kernel as a part of the cell evaluation process. That this is indeed the case, you can confirm by evaluating
$Context variable in such a cell. How and at which stage this is done I don't know, perhaps someone will add this info.
$Pre function, if defined, to the input expression.
$Post function, if defined.
Out[n], stripping off any formatting wrappers.
$PrePrint function, if defined.
MessageList[n] and clear
Print expression, if it is not
Clear any pending aborts.
CellEpilog, if defined for a given cell.
Notation` package hooks into
MakeExpression. What this means is that the notation changes one can do with it are limited to what is possible to do on the level of fully parsed boxes, rather than strings. In other words, your input must represent a syntactically valid string of Mathematica code, for the purposes of parsing to boxes.
This means that there will be a number of things you can not do, such as change the precedence of operators, or introduce syntax which won't normally parse to boxes. Generally, this means that you can not assign custom string syntax, rather you can somewhat augment Mathematica's one, within what can be done on the box level.
Another limitation of
Notation` is that, since it is based on
MakeExpression, and the latter is not called by
Get (which is called to read in packages),
Notation` will not work for packages without some extra work-arounds. One such work-around I suggested here. While it is really a rather ugly hack, it illustrates the way
Notation` works, to some extent. More information about the workings of
Notation` can be obtained, of course, by reading the source code of
Some additional sources of information include
- Reference pages for the functions or options such as
- A good brief (but dated) description is the 1992 WRI technical report "Mathematica internals" by David Withoff (available online as .pdf).
- Some interesting investigations on the order of some of the operations here were carried out by Alexei Popkov in this question.
I am almost certain that I missed or misrepresented something, simply because I don't have a lot of personal experience with all this steps, or exhaustive tests performed to test this description. If you found a mistake, feel free to edit.