[Haskell-cafe] Top-level state debate on the wiki
Keean Schupke
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
APIs,
however I think we are in general agreement...
Keean.
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
generator
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
>thing.
>
>
Yes, I think it is a sign of good modularity.
Keean.
More information about the Haskell-Cafe
mailing list