> For this particular syntax, SAVE probably could handle the expression (since > you used the '-struct' flag) and generate variables with reasonable names in > the MAT-file.
It seems like you could approach this a few different ways. First, like you say, if SAVE could figure out the '.' notation, then allow 'struct.field' storage, requiring a new '-structindex' flag even, but not any of the other strings that would need to be evaluated.
Another way is to leave the behavior as is (only allowing storing of direct variables). But a third way is to allow storing of data, but not storing of _creation_ of data. Sin(A) "creates" data in the sense that it has to allocate new memory to store new data. Whereas struct.field or A(2:3,5:7) is accessing data that already exists.
> But what should the variable in the MAT-file generated by this call be > named? > > save('myfile.mat', 'sin(A)') > > Okay, SIN is a function and that expression is more complicated than your > simple attempt to index into handles with the dot-notation. Fair enough. > Let's take another indexing example, though. What should the name of the > variable in the MAT-file created by this SAVE call be? > > A = magic(10); > save('myfile.mat', 'A(2:3, 5:7)') > > Calling it A would be misleading. I suppose we could pass that expression > through GENVARNAME but the generated variable name is kind of long and > that's a fairly simple example. >
What's wrong with calling the data 'ans' in the .mat file?
If the user doesn't want to name the variable, then they should at least have the foresight to give a good file name:
A = magic(10); save('Magic10Values_23_57'),'A(2:3, 5:7)');