Question: Is it possible to import an MX file saved using DumpSave without evaluating the contents?
Let me illustrate:
Let’s create a variable, data:
In[2]:= data = Range[10]
Out[2]= {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
It can be exported to and imported from MX without making any definitions:
In[3]:= ImportString@ExportString[data, "MX"]
Out[3]= {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
But what if we use DumpSave?
In[4]:= DumpSave["data.mx", data]
Out[4]= {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}
(And clear data)
In[5]:= Clear[data]
On re-import, nothing is returned:
In[6]:= Import["data.mx", {"MX", "HeldExpression"}]
But the variable data becomes defined again, as if we had used Get.
In[7]:= data
Out[7]= {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
I would have expected to get something like Hold[data = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}], i.e. something similar to what would be written to an .m file when using Save.
Perhaps it’s technically impossible to avoid the definition being made because DumpSave and Get directly manipulate the kernel state instead of writing and reading an evaluatable definition like Save does? This is just a guess.
(edit) please note: I am not trying to save in a way that can be imported “Held”. I can already do that using Export. I am looking to import previously DumpSaved MX files instead.
Answer It appears it is impossible to do this unless the MX file was saved to specifically allow it.
My understanding is that the logic of .mx files is the inverse one: when you load an .mx file, the definitions (
DownValuesand others) for symbols are created at the lowest level, so that the values are assigned directly to the internal memory locations, by-passing the main evaluator. This is the reason why loading .mx files is so fast. It seems that you can’t have both – your expectation corresponds to a higher-level symbolic code. You can, however, encapsulate your data by using symbols in some context, as handles for that data.So, I don’t see a real problem here, since you can always query the
DownValuesand other...Valuesof symbols and extract the r.h.sides of the rules in unevaluated form (there are some pathological cases for whichDownValuesdon’t fully reconstruct the original definitions being stored in them, but they are, so to say, of measure zero, and not much practical importance). You can define certain interface, which would allow you to extract your data via a few functions (symbols), while the data can use many more symbols under the cover, which would be hidden behind those.EDIT
If you control the initial use of
DumpSave, here is an illustration of one possibility – you can create a customdumpSave-like function. These are helper function to prepare information on symbols:for example:
Now, the main function:
You basically designate a single symbol as a storage of unevaluated definitions of other symbols. Here is how you can use it:
If you now clear the
storagesymbol and load back the file, you will observe that all definitions of other saved symbols are stored in unevaluated form inDownValuesofstorage. You only need to callReleaseHoldon them to actually execute the assignments, but you also have access to them in unevaluated form.