[Haskell-cafe] Re: [Haskell] Top Level <-

Yitzchak Gale gale at sefer.org
Thu Aug 28 18:06:01 EDT 2008


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


More information about the Haskell-Cafe mailing list