deriving instances of Storable

[mike V]

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..



_
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus

___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi

Re: Bound Threads

[mike V]

For what it is worth I favour Daan's approach, adding keywords to a language 
seems to want for a sufficiently rich formalism/framework.

3) maybe we should also add "forkUnbound" that forks a haskell thread > 
that can automatically be moved between OS threads.
In the spirit of searching for the most basic primitives - why not instead 
define a primitive for moving haskell threads from os thread, as this 
primitive seems to be required in any case in order to effect the 
"automatic" movement between threads. Such a primitive would allow 
alternative thread management strategies to be defined in haskell.

forkUnbound could then be implemented by registering the haskell thread with 
the thread manager etc...

such a strategy would require explicitly identifying os threads - making 
them almost first class, so to speak - is this bad ?

whilst ...

  We never want to specify what OS thread is running a particular
  Haskell thread.
in order to define strategies where the above is true, I believe we do need 
to be explicit. These strategies can either be implemented by the rts, or in 
a library. I think that the latter is better in the sense of more open.

explicit movement of Haskell threads between OS threads could potentially be 
extended to thread migration between processes?

* "forkOS" doesn't have to use a new OS thread to run Haskell threads, just 
when calling a foreign function, so it would work on Hugs too for example. 
(as explained
why complicate matters, if forkOs/forkNative is supposed to fork a native 
thread then why introduce exceptions, as is not forking of a native thread 
part of the meaning of the operation?





_
MSN Instant Messenger now available on Australian mobile phones. Go to  
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp

___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi