Lennart Augustsson wrote: > I don't think anyone has claimed that any interface can be implemented > without globals. > Of course some can't (just pick an interface that is the specification > of a global variable). > What I (and others) claims is that such interfaces are bad. Using a > global variable makes an assumption that there's only ever going to be > one of something, and that's just an inflexible assumption to make.
Not true, it's an idiom that comes up often enough. The "right" way to do these kinds of things is to provide some sort of context around the calling function. Something like withAcquiredResource $ \handle -> do ... You (and others) are right that this is better than trying to keep global state in the context of the called function. The problem is that it is not always possible. There are situations in which you simply cannot make demands on a prior context. One important example is when refactoring a single component within an existing mature system. Another is when writing a library for general use if such demands on the calling context seem onerous for the service that the library provides (this latter is the situation for Data.Unique, according to many opinions). I find that Haskell's composability properties help it to outshine any other development environment I know. Experience shows that this is eventually true even for IO related issues - but those generally take a lot more work to discover the right approach. I feel that here we are still working on "tackling the awkward squad". However we work that out, right now we need a working idiom to get out of trouble when this situation comes up. What we have is a hack that is not guaranteed to work. We are abusing the NOINLINE pragma and assuming things about it that are not part of its intended use. We are lucky that it happens to work right now in GHC. So my proposal is that, right now, we make the simple temporary fix of adding an ONLYONCE pragma that does have the proper guaranteed sematics. In the meantime, we can keep tackling the awkward squad. Thanks, Yitz _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe