"Manuel M. T. Chakravarty" wrote:
If hslibs is meant to be used with systems other than ghc, too - which I think was the idea - there is no choice but to rewrite it into H98. But I guess this is essentially up to Mr. HsLibs aka SimonM.
Well, doing some simple local transformations to get H98 compliance should be possible without consulting Mr. HsLibs in advance. :-)
[ peekArray argument order ] Sounds reasonable to me.
OK, so let's change this before too many programs use the old order.
[ MarshalString ] Hmmm, yes, although pointer/length pairs are not very common in C and this module is a language dependent module (and so should be called `MarshalCString').
Granted. And remember we already have a (quite ugly) module CString! So here is a new proposal: * Deprecate the old definitions in CString and add type CString = Ptr CChar mallocCString :: String -> IO CString peekCString :: CString -> IO String pokeCString :: CString -> String -> IO () withCString :: String -> (CString -> IO a) -> IO a newCString :: String -> IO CString * Add a new module CStringLen with type CStringLen = (CString, Int) mallocCStringLen :: String -> IO CStringLen peekCStringLen :: CStringLen -> IO String pokeCStringLen :: CStringLen -> String -> IO () withCStringLen :: String -> (CStringLen -> IO a) -> IO a newCStringLen :: String -> IO CStringLen
[ MarshalError ] But SimonM said that he doesn't want to make errno Haskell thread local...
Wasn't this only due to efficiency reasons? IIRC Fergus had a good suggestion (copying errno only on thread switches or something), so I'd like to hear Mr. HsLibs' opinion on this topic again.
[ MarshalUtils ] BTW, can't we just use `with' now. IIRC, the only reason Marcin used `withObject' was because of a clash with the implicit parameter extension. This has been changed now, hasn't it?
Nope, not yet. Although there was some consensus about SPJ's ?-suggestion for those bindings, it's not implemented yet. Any takers? If this has been done, `with' would be better, indeed.
[...] This is also along the lines of what Marcin proposed. So, let's use it.
Well, it *is* what Marcin proposed. :-) I only gave maybe ($nullPtr) a name and a (less general) signature.
[ module (re-)exports ] I was thinking of an extra module mainly because the MarshalXXX code is system independent - in contrast to the code in `Foreign'. However, we may also just let Foreign do the whole job. Thinking about it again, I doubt that anybody will ever import one module, but not the other - so, let's make Foreign export the whole lot.
There is one exception: MarshalCString shouldn't be re-exported by Foreign (like CTypes).
I'd opt for this too: Foreign re-exports MarshalAlloc, MarshalArray, MarshalError and MarshalUtils and *not* CString/CStringLen.
And just a final topic which really should be settled: "Marshal" or "Marshall"?? :-}
I would have taken the latter, but I think, SimonM originally proposed the name MarshalUtils with one "l" and as he is the native speaker...
*sigh* Have to change HOpenGL once again... :-P If there are no further objections I'll incorporate the MarshalXXX and CSTring{,Len} stuff into hslibs this weekend. Cheers, Sven