Re: Problem loading/saving of lists and structures.

[Steven G. Johnson]

>I'm not opposed to supporting different file formats, but I'm not sure
>that it makes sense to overload the load and save functions to handle
>every new file format that people might want to have.

Okay, I see your point.  If you add M new types and N new formats, the
current scheme requires O(M*N) coding work, whereas you would really like
only O(M+N) work (which I think is the lower bound for practical purposes).
Here's a suggestion for achieving that:

For HDF5, at least, and for some other formats where we have sufficient
control of the output (e.g. the native Octave formats), all we really need
is a unique tag string for a type, a list of primitive data types it
contains, their quantities, and routines to get the values for those
primitive types.  But this is *exactly* the same as mapping the data type
onto an Octave structure or a list.  Thus, the simplest thing to do in
order to handle random new exotic types would be to supply a routine to
convert the type into a standard Octave type (for example, a structure),
supply a unique "tag" string for the variable so that the file knows it is
not an ordinary instance of that type, and supply a routine for converting
back.

For example, a structure array might be stored as a list of structures,
with a tag "OCTAVE_STRUCTURE_ARRAY" so that the loader knows it needs to
pass it to a conversion routine upon input.

Each specific filetype is going to have to supply special routines to
load/store the primitive types (arrays, scalars of various types, and
structures) in any case.

For formats like MATLAB where one doesn't have much control, one is going
to need special-case code in any case to recognize "special" types like
sparse matrices and map them onto the appropriate Octave type.  I don't see
how you can get around this.  But at least, this way, if you need to import
a new "special" type, you don't have to do O(M) work to be able to export
it to all of the other formats.

Steven