[Haskell-cafe] Re: [Haskell] Re: Global Variables
and IO initializers
k.schupke at imperial.ac.uk
Mon Nov 8 14:43:26 EST 2004
Just to add a small point... you can see how the 'bad' single context
design affects the code that uses it. Because C allows global variables
it is possible to write libraries that require once-and-only-once
In Haskell (without global variables) it is impossible (or at least
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 Schupke wrote:
>> Any C library which requires an explicit initialisation call before
>> in that library can be used (common enough IME). Accidental
>> (e.g. by two independent modules/libraries) will destroy any state
>> 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.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe