25
$\begingroup$

Can anyone sort out what the Front-End is, how it is structured and what its relationship to the Kernel is. The FrontEnd is mentioned quite often but elusively avoids to be caught and clearly defined.

I think I understand that a notebook is a textual and graphical interface, and it is part of the so-called FrontEnd which is run by the kernel. But my understanding of its place and function in the Mathematica hierarchy, is unclear to me.

Here at SE, users are often encouraged to occasionally restart a notebook and sometimes even the Kernel to deal with certain problems. What happens here? I also see that some dynamic code works in a newly opened Notebook without an evaluation has been performed.

Anyone care to uncover the mystery?

Improve this question
$\endgroup$
6
  • $\begingroup$ A seemingly very basic question that could potentially have a complex and important answer. +1 $\endgroup$
    – Mr.Wizard
    May 23, 2015 at 10:04
  • $\begingroup$ I started an answer and posted it below but I realize that I could potentially go in a number of directions from here. To prevent it from becoming an aimless ramble would you please take a look and give me some guidance? $\endgroup$
    – Mr.Wizard
    May 23, 2015 at 10:23
  • $\begingroup$ @Mr.Wizard I did the same search you mentioned, but didn't find any clear definition. Your answer is certainly helpful and I hope more will be added. You say some commands are managed by the Front End and some by the Kernel. I thought everything is ultimately driven by the Kernel. You see, I still don't understand how code is "run" in the Front End i.e. outside the Kernel. $\endgroup$
    – MathLind
    May 23, 2015 at 10:47
  • $\begingroup$ Okay, I'll try to give my understanding of that aspect. Actually I think I'll have some coffee and breakfast first. :^) $\endgroup$
    – Mr.Wizard
    May 23, 2015 at 10:48
  • 3
    $\begingroup$ LinkSnooper ought to be mentioned (e.g. q/18719) as well as the main, preemptive, and service links (e.g., see this chat exchange). One can observe what is done and communicated in each of the FE and kernel with LinkSnooper. $\endgroup$
    – Michael E2
    May 23, 2015 at 10:56

2 Answers 2

Reset to default
15
$\begingroup$

I looked for a documentation section that concisely defined what the Front End is but I did not find one therefore I shall attempt my own definition. I admit I have never considered this in detail nor dug into the low level connection between the Front End and Kernel, so this definition is bound to be incomplete and possibly incorrect.

The Front End is the entire GUI (graphical user interface) to Mathematica. It is the implementation of the Notebook Interface. The alternative is a text-based (command line) interface.

The Front End is responsible for accepting input from keyboard, mouse, etc. Typed input is converted into Box representation(1)(2)(3) that can be passed to the Kernel. Menu commands, mouse clicks, etc., perform operations that may be applied by the Front End itself or which invoke Kernel evaluation, or a combination of both.

The Front End renders Box forms, directly input or passed back from the Kernel, in a human bearable way. These range from the simple RowBox, SubscriptBox types to all graphics and dynamic expressions. (One may use the menu command Cell > Show Expression to see the box structure of any Notebook cell.) Syntax highlighting, spacing and line breaks are applied by the Front End.

Some Front End rendering requires interaction with the Kernel. In recent versions even FrameTicks may rely on Kernel evaluation so graphics may not display completely until a Kernel is started and definitions are loaded. Dynamic expressions have their own evaluation channel to the Kernel in parallel to the normal evaluation channel employed by Shift+Enter.

Improve this answer
$\endgroup$
7
  • $\begingroup$ I believe Animator and Clock have a special implementation in the Front End. (See, for instance, my answer to Why animator smoothes dynamic updates, or how to make pacman drink beer.) $\endgroup$
    – Michael E2
    May 23, 2015 at 11:03
  • $\begingroup$ @MichaelE2 Would you care to collaborate if I make this answer a wiki? Or post your own answer? (Or neither I guess.) $\endgroup$
    – Mr.Wizard
    May 23, 2015 at 11:05
  • 1
    $\begingroup$ I'm going on a trip after breakfast. My time and access might be limited for a few days. Which is why I chimed in with only a couple of comments. We can see how it goes, but for now I don't think I'd be able to fully participate. (But thanks for the invite!) $\endgroup$
    – Michael E2
    May 23, 2015 at 11:17
  • $\begingroup$ @Michael Okay. I hope the trip is fruitful and/or enjoyable! I'll be out for the day myself. $\endgroup$
    – Mr.Wizard
    May 23, 2015 at 11:18
  • 3
    $\begingroup$ When Dynamic[] objects are involved, the connections between the front end and the kernel are more complicated, with three distinct links between them. This is explained well in Advanced Dynamic Functionality / Synchronous versus Asynchronous Dynamic Evaluations. $\endgroup$
    – Emilio Pisanty
    May 23, 2015 at 23:46
13
$\begingroup$

This answer is not meant to compete with @Mr.Wizard's answer, but to serve as a addendum presenting a historically-oriented view.

In the early days of Mathematica the dichotomy of front end and kernel was simple. Mathematica had a client-server architecture: The front end was the client and the kernel was the server.

The client's job was to manage the GUI, which could be broken into the following tasks:

  • Get input from the user and typeset it on the screen.
  • Translate input forms into kernel forms (think of these as FullForm) and send them to the server.
  • Receive replies (evaluated forms and messages) from the server.
  • Render the server replies on the screen (graphics rendering and more typesetting).

The server's job was to run the form evaluation engine on the forms received from the client and to return the resulting form (and perhaps some messages) when the evaluation reached a fixed point.

Since the introduction of Dynamic into the front end and support for parallel processing over multiple kernels this simple model has blurred, but perhaps it is still useful as a first-order approximation.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thank you. The historical perspective is helpful in understanding the origin and evolution of the Front End. The term "blurred" describes both its role and my past understanding of it pretty well. However after reading your answers it's getting clearer. $\endgroup$
    – MathLind
    May 23, 2015 at 13:05
  • $\begingroup$ As you say, it has gotten blurred, but for the most part I pretend that it's still a simple client-server relationship unless I have to consider that it's actually not (e.g. w/ Dynamic[]). $\endgroup$
    – J. M.'s slightly less busy ♦
    May 23, 2015 at 16:50
  • $\begingroup$ @J.M. Dynamic is still pretty much client-server, if my understanding of it is correct. The kernel can track variable changes via the Names["Internal`*Track*"] functions and the front-end configures listeners for that. What's more interesting is the stuff like Names["FEPrivate`*"] which, with it's Mathematica-like syntax and limited scope (and the fact that it can only run in the FE), suggests there's something like a small kernel running in the FE. $\endgroup$
    – b3m2a1
    Aug 31, 2017 at 19:47

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.