In my view, the Mathematica front end would have needed a complete rewrite a long time ago to be in a shape where it can compete with modern UI's. Looking at MATLAB, it's clear that you always find things that are even more out-of-date. Also, I don't want to say that you can't create beautiful content inside a notebook. However, especially the capabilities of the notebook's editor carry a lot of technological depts.
One of the major problems is how you make the knowledge of the kernel available to the front end for autocompletion, highlighting or even code inspections. In a perfect world, the front end would simply ask the kernel questions like
- What existing functions match "Plo*"?
- What is the highlighting of
myFunc
?
and use this information for highlighting. However, this has proven to be too slow or too heavy when you consider how often you get autocompletion pop-ups and how much code needs to be highlighted. As a side note: The original implementation of the front end's autocompletion did exactly that. It always asked the kernel about defined functions.
My feeling is that Wolfram moved to an approach where they keep these pieces of information in the front end and try to sync with the kernel when you evaluate code. In fact, when you use the LinkSnooper to peek into the information flow, you see that each evaluation is combined with the front end asking the kernel for all defined symbols.
For FunctionInformation
it appears to be similar. That means when you evaluate
SyntaxInformation[f] = {"ArgumentsPattern" -> {_, _}};
the only thing the kernel does is to put the information in the DefaultValues
. The real trickery is that the front end captures this call to update its own function information. This is done with the front end function
FrontEnd`SetFunctionInformation[...]
Important is that both things are separated and only what the front end knows will be used for highlighting. Now, we are ready to answer your questions with the usual disclaimer that I don't have more information than what spelunking tells me:
- Why does defining SyntaxInformation for a symbol add definitions to DefaultValues?
We need to look at this from the point of the Mathematica kernel of the year 1990. Fancy highlighting for arguments did not exist, but the different bags of rules where information about a symbol could go were already there. We have DownValues
, OwnValues
, UpValues
, Messages
, and DefaultValues
. I guess the only half-decent place where you could put a thing like the function information rules is in the DefaultValues
. It's not intuitive, but it's probably the least harmful way to do it. If a call to SyntaxInformation
is supposed to attach the given information to the symbol, it needs to go into one of the rule bags, and I guess Wolfram decided that the DefaultValues
were a good place.
- Why do built-in symbols with syntax highlighting not have DefaultValues associated with them?
Because they are never called with SyntaxInformation[..] = ...
. What Mathematica does is to use the syntax information you find in
$InstallationDirectory/SystemFiles/Kernel/TextResources/English/FunctionInformation.m
and call FrontEnd`SetFunctionInformation
directly. These definitions never see the kernel. For more details, please look into the file
FileNames["GetFEKernelInit.tr", {$InstallationDirectory}, Infinity]
and search for SetFunctionInformation
.
- Running DefaultValues[f]={} does not remove the syntax highlighting. But does manually clearing DefaultValues for a symbol cause any problems?
Besides that calling SyntaxInformation[f]
won't give you the rule anymore while the front end still highlights it according to your settings, I don't think there are further problems. Btw, you can also do this the other way around: Tell the front end that there is a function to highlight, while there is none:
info = {{"Global`", {{"func", {_}}}}};
MathLink`CallFrontEnd[FrontEnd`SetFunctionInformation[info]]
Now, you have autocompletion for func
and it highlights missing/excessive arguments, but the kernel has absolutely no clue about func
. Even cooler is doing this with Plot
because then the FE (yeah, I'm finally abbreviating this) thinks your stupid soul tried to add another global Plot
definition and marks it with red :)
- Bonus Why does MatchQ[DefaultValues[f], DefaultValues[f]] yield False after setting SyntaxInformation for f.
From the documentation:
Verbatim[expr] represents expr in pattern matching, requiring that expr be matched exactly as it appears, with no substitutions for blanks or other transformations.
Therefore,
MatchQ[DefaultValues[f], Verbatim[DefaultValues[f]]]
(* True *)