# What is the purpose of Dump contexts?

## Motivation

I've been trolling through some internal code, trying to glean design practices WRI developers employ when extending Mathematica using top-level code.

During my ??...-- type searches, I've encountered a number of contexts named either like SomePackageDump or with Dump appended as a subcontext of SomePackage.

## Question

What is the designed purpose of these Dump contexts and how exactly are they employed (in the overall scheme of evaluation)?

Note: I understand the use of Private subcontexts. :)

-
@telefunkenvf14 I think the likely explanation is that the contents of these contexts is loaded directly from a dump (.mx) file. Their actual use seems to vary between "just throw anything you like in here" (Manipulate; System) and defining symbols that you want to export from Private but which are not supposed to be called directly by the package user (ComputationalGeometry; DiscreteDivisorSumDump). I personally prefer the latter approach. –  Oleksandr R. Sep 17 '12 at 17:35

The Dump contexts appear to be loaded when .mx files are requested. These are in machine code for a specific system, and are in the same form as the file you will get if you use the function DumpSave. You will find the .mx files in the ../../SystemFiles/Kernel/SystemResources/YourSystem/ folder. These are generally not loaded until you request a function that accesses them. For instance after you use a StableDistribution function, if you then call,

Names["StatisticsStableDistributionsDump*"]


you will get a listing of all the functions which have been added.

These files are apparently already compiled, are more compact, and load faster than standard packages, but they are machine and sometimes Mathematica version specific.

-
Yes, I said this much in my comment above... it doesn't answer the question, though--i.e., given that a dump file can contain arbitrarily named contexts, why is this naming convention used? –  Oleksandr R. Jan 6 '13 at 1:52
I suspect it is an enforced style. Interestingly, sometimes the code is not ReadProtected, so you can get it all with the following: snames = Names[StatisticsStableDistributionsDump*"]; ToExpression["??"<>#]&/@snames; First you need to call a function which loads the mx package. –  Bob R Jan 6 '13 at 1:56
ReadProtected doesn't prevent one from reading those definitions, either--you can just clear the attribute. Things hidden behind ReadProtected are usually not a big secret; it is simply set to avoid overwhelming the user with a lot of irrelevant implementation detail. Anyway, the question asks, why does this convention exist, and what does it signify? You and I can certainly speculate about this, but IMO the only people who can actually answer are the WRI employees, who apparently choose not to do so. –  Oleksandr R. Jan 6 '13 at 2:03
It seems obvious to me: Dump signifies that the code is coming from a machine specific .mx file rather than a package which could be loaded on any machine. Thus if you are working on a development team and you think something needs to be changed, it has to be recompiled for every machine. –  Bob R Jan 6 '13 at 2:10
I aggressively beta tested the StableDistribution package, working closely with the developer. Whenever I found something that needed to be changed, he was able to send me a specific .mx file for my machine so I could test the fix. Surely I am speculating about the word Dump, but before the function name was changed to DumpSave, it was just called Dump. It is specualtion with experience. It is helpful to know whether the error code comes from code in an mx file or a standard package, there is no other ID, when you get an error message in beta testing. –  Bob R Jan 6 '13 at 2:30