[Haskell-cafe] Re: [Haskell] Top Level <-
jonathanccast at fastmail.fm
Thu Aug 28 15:41:14 EDT 2008
On Thu, 2008-08-28 at 20:28 +0100, Adrian Hey wrote:
> 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).
> I said in the original challenge even I'd let you (anyone) change the
> interface if you could provide a sensible explanation of why the
> new interface was better, safer, more convenient or whatever.
> > 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,
> It's not an assumption, any more than I always want 1*N to yield N is
> an assumption.
> It's a fundamental property I absolutely want to guarantee. By far the
> simplest way to do this is simply not to expose a newWhatever
> constructor in my API. If I expose anything it should be Whatever itself
> or getWatever, neither of which is possible if Whatever contains MVars,
> Chans and the like.
This has been answered repeatedly, at least implicitly. Unless you
insist that getWhatever should live in the IO monad and have no
functional arguments (why?), there is no reason why this should be
> What's more, there seems to be no good *semantic* reason why this should
> not be possible. The only objections seem dogmatic to me.
I haven't seen you give a non-dogmatic reason for wanting global
variables yet, either.
> > and that's just an inflexible assumption to make.
> > You think global variables are essential, I think they are a sign of
> > bad design. So we have different opinions and neither one of us is
> > going to convince the other.
> You might stand some chance of convincing me by showing a better
> design :-)
> Dan seems to have had a reasonable go at 1 of them. I'm not sure
> passes the improved interface test but I'll think about it. But
> there are quite a few left.
There are even more implemented in languages such as ML, Lisp, Perl,
etc. I think habit and the fact that globals sort of work in Haskell
are the major drivers of their use in the existing standard library.
See my position as an attempt to drive back those battalions of
> There's the Hughes paper too of course, using implicit parameters
> (a highly dubious language feature IMO).
> But even if someone does produce an entirely unsafePerformIO hack
> free set of standard libs, I have to ask why jump through all these
To improve the APIs available? You're advocating an extension to a
*purely functional programming language*. That's an awfully weird hoop
you've already jumped through, there. Some of us think it logically
extends to condemning global variables; I haven't seen you give a reason
> There's no semantic difficulty with the proposed language
Although I've noticed it's grossly under-powered compared to what's
needed to implement stdin the way you want to.
More information about the Haskell-Cafe