Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

Adrian Hey ahey at
Mon Nov 22 03:38:00 EST 2004

On Friday 19 Nov 2004 2:27 pm, Benjamin Franksen wrote:
> Implicit parameters are evil, agreed. Their deficiencies should be added
> as a warning to the docs (with many exclamation marks). 

Well I dunno. Maybe whatever's currently wrong with them can be fixed up.
But I can't say they're something I've ever felt a need for.

But it's ironic that some folk advocate the use of this (mis?)feature as
a solution to the (so-called) "global variables" problem. I don't like
this idea at all, but at least they recognise that there is a problem. 

> But toplevel
> things with identity (TWI) are evil as well, *especially* if they are
> easy to use.

Just repeating this again and again doesn't make it any more true. Neither
you or any of the other nay-sayers have provided any evidence or credible
justification for this assertion, nor have any of you provided any workable
alternative for even the simplest example. Lennart has yet to explain how he
proposes to implement his supposedly safer "openDevice". You have yet to
explain how you propose to deal with stdout etc..

BTW, top level TWI's are easy to create anyway, via the *unsound*
unsafePerformIO hack. The evil here not their existance, it is the
unsoundness of their creation mechanism. Given that in the absence of
anything better folk are going to continue to use this (because it
really is necessary sometimes), objecting to the provision of a sound
alternative is just silly. This is the "militant denial" I was talking

And of course there's one top level TWI that none of us can live
without. I am refering to the unique and stateful "world" that is
implicitly referenced by all IO operations (with the possible
exception of those operations I would like to put in the "SafeIO"
monad). So is this evil too? Perhaps it is, but if so, I'd like to
know how you propose to live without it and what purpose the IO monad
would serve in such a situation.

Adrian Hey

More information about the Haskell mailing list