[Haskell-cafe] Top-level state debate on the wiki
k.schupke at imperial.ac.uk
Thu Dec 2 07:42:09 EST 2004
Just a few minor nitpicks... mainly about the necessity of using certain
however I think we are in general agreement...
John Meacham wrote:
>That example solves a different problem, I was never claiming that
>there wern't efficient ways to solve the unique producer problem in
>general, just no efficient way to provide the interface as given in
>Data.Unique, a top level declaration of type 'IO Int'.
My argument would be program in the idomatic style of the language,
rather than change the language. In other words it is not necessary
to implement that API, it is a preference.
>If you are allowed to replace code at will then nothing anywhere is
>guarenteed in haskell :) I mean you could replace head with
>head = error "No head for you." and a lot of libraries would break.
I am only talking about substitutimg modules... you can simply
feed ghc a different search path with -i, and insert a wrapper
around the module. My point was it is a possible way to take
a third party library that supports only one global context and
get it to support many contexts without changing a single line
of code in the library itself, and this is a good thing IMHO.
> Yes. but that has the same problem as your other example. it is a
>different interface than the one we want. If we want to pass around the
>state we can use many of the other routines in Random. If we want to
>extend the world with the standard generator (which is perfectly
>reasonable, and useful enough to make it into the standard haskell
>libraries), we are out of luck.
But you can use this different interface - it may not be the one you would
like - but it does the job. My point was it is not necessary to have a
with the API you gave, again it is a preference.
>Yeah, I imagine this functionality would be useful to implement
>debuggers like 'hat' where you need to collect 'meta-information' about
>a run of the program. again, I don't see the ability to replace library
>calls like IORef as a weakness in the guarentees provided by stuff that
>uses them, as it is up to the replacer of the libraries to do the right
Yes, I think it is a sign of good modularity.
More information about the Haskell-Cafe