Declare exported functions as IO, call initialize internally instead of exporting it.

[adrianmay]

Previously, some of the exported haskell functions were declared pure but used unsafePerformIO internally. That just encourages the calling code to lazily skip the call. Now, everything correctly returns IO.

It had been obligatory for callers to call initialize before anything else, but when the ultimate calling code uses this library indirectly through other libraries, it's not clear which package should call initialize. The logical answer is that this library should do so itself, so now it does so in fec. It's not possible to call encode or decode without having obtained a handle from fec, so those functions don't need to worry about initialization. There is a slight overhead that subsequent calls to fec must call into C to check the boolean that says whether or not it's been called already, but then they bail out fast.

A better solution to all of this would be if the numbers that fec_init stuffs into the four tables were simply defined in C as initialized data. Then there'd be no initialize function, not even internally. Since the handle returned by fec is per-client and does not get modified by encode or decode, the whole library would then be implicitly thread safe but for the danger of a client freeing their own handle too early. It would also be pure, i.e., there'd be no IOs in sight. Both would be huge improvements. The numbers would be generated by a pre-build step that runs the logic of fec_init and dumps the results in C syntax. That should be considered for a future ticket, but the present goal is just to get everything working.

[hacklschorsch]

I like the description of this MR! Can you put the first two paragraphs into the ChangeLog.md and the last paragraph into a new ticket?

[hacklschorsch]

I understand this as kind of a constructor - is this the naming convention in Haskell Land? No "init" or "setup" or "create"? (I know the function was called "fec" before).

I find it a bit confusing between all the different fec functions, but that might be my as-yet under-exposure to Haskell code.

[adrianmay]

There's only one fec and this is it. Previously it was wrapped by setupFEC which returned IO and called initialize. Now that both of those things are true of fec itself, the wrapper would be a synonym, so I removed it.

[hacklschorsch]

A more speaking title would be nice - this PR changes the interface and quite a bit in general

[hacklschorsch]

Can we keep the old initializing interface (setupFEC(), more?) around, but make it a no-op (maybe emit a warning at compile time), so people can upgrade more easily?

[exarkun]

See also #84

[hacklschorsch]

Doesn't the removing of the upper version constraints in the cabal file mean we can't publish the library to hackage anymore? (Asking because it's already there: https://hackage.haskell.org/package/fec)

[hacklschorsch]

If we can keep the initialize call but make it a no-op we don't have to bump the major version, right?

[adrianmay]

Actually we need to bump the major version anyway cos everything returns IO now. That's also a breaking change, and an unavoidable one cos not returning IO from something that has side effects was probably the problem all along.

[adrianmay]

See also #84

Shame it didn't happen. I think the unsafePerformIO is the real reason for the "race condition". Haskell can't prove that it needs to do something that returns () if it doesn't see it as IO.

[adrianmay]

I like the description of this MR! Can you put the first two paragraphs into the ChangeLog.md and the last paragraph into a new ticket?

Done: #126