Persistant (as in on disk) data

[mike V]

Here is my post from the ffi mail list and some comments. Although not 
directly related to your question, I believe this whole issue merits further 
discussion, which unfortunately did not ensue with my post on the ffi mail 
list. And indeed from time to time it does seem to pop-up. I guess it is 
like the uncomfortable bed, never uncomfortable enough to be rid of.

1. The answer to your question: look at the Binary package (haskell libs) 
which implements a class Binary that allows binary IO, whether this package 
suffers from bit rot I don't know.

2. That haskell does not support a "Binary IO Standard" I believe to be an 
issue. An issue which with the advent of a "Standard FFI" is ripe to be 
addressed.

2.1. The binary package mentioned above implements it's own marshalling 
library which could to some extent(see 2.2.1) be subsumed by the FFI 
libraries.

2.2. The function of the Binary Class could be replaced by the Class 
Storable .ie. what is Storable can be written.

2.2.1 Notwithstanding the above, Class Binary may still be required. Haskell 
may opt for a "Standard Serialised" format across all platforms - this 
distinction comes into play with Big-endian vs little-endian int 
representations etc. Which for Storable does not come into play as by 
default you whish to have the same representation as the standard platform 
representation. Candidate representations could be ASN, XDR there are plenty 
of them (I believe that DCE, CORBA, Java etc all define some sort of 
standard serialisation).

2.2.1.1 There may be a need to define a set of data types similar to the 
CForeign package eg XDRInt etc, but on first inspection I believe them to be 
unnecessary.

2.2.2 A standard serialised binary representation would be of some benefit 
allowing sharing of binary files across platforms.

2.3 Class Storable or Binary could be made derivable, thereby facilitating 
the easy marshalling of structures to disk, see note below.

2.4 I guess it all comes down to whether the Haskell community feels that no 
standard binary io is ok.

deriving instances of Storable
Wed, 05 Feb 2003 20:37:25 +1100

Previous message: haskell finalisers driven underground
Next message: deriving instances of Storable
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--------------------------------------------------------------------------------

Is there any merit in the idea of allowing instances of Storable to be
derived in a similar fashion to Show, providing that constituents are of
class Storable.

for instance

(Int, Int)


two Ints would be marshalled into consecutive memory locations in their
order of declaration.

(Int,String)

an Int followed by a String

dealing with constructors
==========================
data X = X1 Int | X2   deriving Storable
data Y = Y1 | Y2 deriving Storable

three possible alternatives spring to mind

A) Indexing Constructors by position

X1 -> 0:Int
X2 -> 1

where
0, 1 represent the constructor indexes
":" represents that the data items are physically contiguous
"->" reads "marshalled as"

This has the disadvantage of being sensitive to the constructor order

B) using the constructor name as the index
X1 -> X1:Int
X2 -> X2

has the disadvantage of requiring a variable amount of memory for the
tag.

C) some other hash on the constructor name ?


I would think that implementation would be fairly straight forward?

The benefits would be significant - automatic marshalling of structures.

uses: storing to disk, passing over network etc etc..



_________________________________________________________________
Hotmail now available on Australian mobile phones. Go to  
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp