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 impossible. > 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 darkness :) > 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 > hoops? 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 for disagreeing. > There's no semantic difficulty with the proposed language > extension, Although I've noticed it's grossly under-powered compared to what's needed to implement stdin the way you want to. jcc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe