That API looks great! But I think you should ask dons for an authoritative opinion :-)

I’ll release it, together with a new blogpost tomorrow. (Don’t have time now, it’s a friday night and I’m on vacation ;)

To give you a preview, I’ve removed ‘unsafeStem’, moved the low-level stuff to a new module (NLP.Stemmer.C) and added (to the exported functions)

withStemmer :: Algorithm -> (Stemmer -> IO a) -> IO a
stem :: Algorithm -> String -> String
stemWords :: Algorithm -> [String] -> [String]

If your memory were so precious that that would be a problem, you’d not be writing your app in Haskell anyway.

I’m pretty comfortable with using unsafePerformIO in a library (but I’m no more seasoned in Haskell than you of course!). You have something that is essentially a pure computation (namely a stemming algorithm) and it should be exposed as such to Haskell application writers.

Using unsafePerformIO in a pure Haskell application usually means that the author made a design mistake, but when you’re talking to C it is OK with me to write wrapper code that deals with the statefulness of the underlying C API, and then run the wrapper code inside unsafePerformIO.

That doesn’t mean you shouldn’t be very cautious when using unsafePerformIO. Looking at my example code, and what you say about the dangers of unsafePerformIO, I see that I should probably have one unsafePerformIO call in the “stem” function, because now it might call “Stemming.stem ” too early.

That said, I’m not a seasoned library developer, so I’m not sure if unsafePerformIO might be fine in these cases. From the documentation: “If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate.” If I understand that correctly it might be that deleting the pointer could happen before a stemmer has been assigned. Since the ‘delete’ function will not fail when passed a nullPtr, this probably should work fine, except the occasional lack of freeing the memory. It’s probably possible to implement it in a way that’s still perfectly safe, I’ll investigate it a bit ;)

I was thinking of an API like this myself:


data Language = English | Dutch | Piraha | ...
deriving (Eq, Ord)

stemmerCache :: IORef (M.Map Language Stemming.Stemmer)
stemmerCache = -- insert dirty top-level unsafePerformIO here


This gives you a nice functional API at the price of making the implementation unsafe*-ridden. What do you think about such a thing?

withStemmer stemmerAlgorithm action = do
  stemmer <- new stemmerAlgorithm
  result <- action stemmer
  delete stemmer
  return result

What do you think?

Have you thought about making the API more Haskelllike? Perhaps you could create and destroy Stemmer objects behind the scenes in global variables (unsafePerformIO FTW).