design affects the code that uses it. Because C allows global variables
it is possible to write libraries that require once-and-only-once initialisation.
In Haskell (without global variables) it is impossible (or at least extreemly
hard) to write such librarys. Haskell libraries tend to allow multiple
concurrent independent threads of access. Allowing global vars into
Haskell would make it easy for coders moving to Haskell from C to carry
on coding in a bad style. It seems correcting the problem outside of
Haskell and in C is the right approach - as it does not involve making
these 'bad' things easier to do in Haskell.
Keean.
Keean Schupke wrote:
Any C library which requires an explicit initialisation call before anything
in that library can be used (common enough IME). Accidental re-initialisation
(e.g. by two independent modules/libraries) will destroy any state currently
be used by the libraries existing "clients".
The need to do this may or may not indicate "bad design" on the part of the
library author. But so what? It just happens to be a fact that must be dealt
with from Haskell (in a safe manner preferably).
You are right, the C library that works like this is "bad design"... any library should really be reentrant, an preferably state free. An example of a well designed C library is the ODBC database connection library, where all the state is stored in opaque handles returned to the user.
For 'broken' libraries that cannot support multiple simultaneous contexts, it would be better to use the 'C' FFI based solution suggested by another poster. Ideally you would want to find a library with a better interface - If you tell me the library you wish to use I may be able to suggest a better alternative.
Keean. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
