Some very good suggestions. I will try to appease Ceiling Cat and
reduce my (perhaps gratuitous) use of unsafePerformIO. I'm going to
have to use it somewhere, since I want referentially transparent code
(and I try to avoid the IO monad when possible, anyway).
> 2. if your function returns Ptr a - then hold in haskell types this Ptr a.
> no need to convert it back and forth to ForeignPtr
Yes, I thought of doing this, but then thought it was better to use a
"managed" foreign pointer via newForeignPtr. I thought this was the best
way to have a foreign pointer that the Haskell garbage collector would eat
it was no longer in use. I could be wrong. I convert from a ForeignPtr to
because the FFI code wasn't compiling at all (nevermind the missing C/C++
problem), as apparently a ForeignPtr isn't the sort of thing that an
function can take as an argument (or so said GHC). I just assumed that the
back-and-forth between Ptr and ForeignPtr would be compiled away by GHC.
I could be wrong, though. If performance starts to suffer, I'll manage the
in my code directly.
> 4. i don't looked in your code but if C functions defines
> *modifiable* datastructure - you should use it at Haskell side via
> imperatiove functions, i.e. those with return type IO a. using
> unsafePerformIO in this case will lead to Haskell compiler will
> consider this datatype as permanent and reorder operations on the will
Good point. I would do this if I planned to train or update the language
from within Haskell, but, as it stands, I just want to train it once (at the
using the built-in mechanisms of SRILM) and then read in the ARPA-formatted
model file for use in Haskell.
> 3. why c_dlm is FunPtr in your definition? it should be
> foreign import ccall "srilm.h deleteLM"
> c_dlm :: Ptr Ngram -> IO ()
No reason. Just because I don't know what I'm doing yet.
Thanks for the correction.
Thanks for the help, Bulat. Much appreciated.
View this message in context:
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
Haskell-Cafe mailing list