> Can anyone help with loading/saving binary files in GHC 0.29? I hear that a
> call to C is necessary, but that is possibly the scariest thing I've ever
> heard ;-)
>
> I have a data structure Library, and two tools. One tool saves a Library,
> another one loads it. At the moment, Library must be "shown" by the first
> tool (i.e. converted to text format). This must then be re-parsed by the
> second tool.
I cannot offer immediate help, only some general remarks (the question
is remotely related to something I had to implement for another
language and directly related to some things I would like to see in
Haskell and other fpls - orthogonal persistence).
> What sort of thing needs to be done?
>
> Many thanks!
>
> Ed
First, the complexity of the problem depends on what is needed and
without someone working on the language (specification and)
implementation, your only hope is that you probably don't need full
persistence (if you can "show" your Library, it probably contains no
functions, unevaluated closures or sharing constraints that need to be
preserved over write/read). Still, loading expressions from files needs
to be integrated with the static type system:
> And the "loading" tool does something like this:
>
> main = getArgs exit $ \as ->
> ... ->
> readFileWithPath path filename $ \the_data_structure ->
What is the type of the_data_structure? With conventional i/o, we can
be sure it is [Char], but if i/o is allowed for all valid language
expressions, a type check needs to be done after input to make sure
that the dynamically loaded item is of the statically expected type.
This also means that the items need to be stored with their type
information. In general, this seems to involve a language extension,
not only a library function, unless you only need to store/load one
type of expressions (in which case you could try to provide i/o for
this type only, similar to the use of [Char] now). Of course, this
immediately brings us to the next problem: reader and writer have to
agree on the types of the communicated objects and the types of objects
in files have to match the types used in readers (including type
definitions; imagine you store your Library in a file F, modify the
type definitions in your tools, recompile them, and try to load an old
version of Library from F into a new version of your tools). System
evolution (changing your program, building new version) now involves
readers, writers, and previously stored files, all of which need to be
kept up to date.
If all this does not matter, you may have a chance to do what you need
by calling C, provided the ghc foreign function interface allows you to
pass objects of your Library type to/from C functions. Sadly, this is
exactly the part on which I can offer no help currently.
| There isn't a good way to do this in GHC at the moment. It would
| be a nice thing to have, but we just havn't got around to it. Any takers?
|
| Simon
As I said, I cannot offer immediate help now, but you may have got
around to it without knowing. Since ghc supports distributed
implementations, there has to be support for distributing arbitrary
Haskell objects to other processors. It may be possible to redirect the
communication between processor memories to a file, i.e., there is a
slight chance that most of the difficult code can be reused for the
purpose of storing/loading data structures. Of course, the requirements
for the two tasks differ, so it will not be possible to reuse code
directly (e.g., code is usually distributed only once, but has to be
stored on each write), and it may not be possible to reuse code in the
required way at all (I am no expert in ghc internals). At least, it
seems worth looking at this option if someone is willing to work on it
(since distribution is closer to the major interests of the ghc
developers, the chance of keeping the implementation up to date would
also be higher; changes to the language/system are likely to be
incorporated in the code for the distributed version and could
- ideally - be shared by the persistency library).
(Needless to say, I would be very interested to hear about any work in
this direction.)
Hope this helps (a bit),
--
Claus Reinke University of Kiel
email: [EMAIL PROTECTED] Department of Computer Science
http://www.informatik.uni-kiel.de/~cr/ Preusserstr. 1-9, 24105 Kiel
