On Thu, 2008-08-28 at 14:45 -0700, Jonathan Cast wrote: > On Thu, 2008-08-28 at 22:24 +0100, Adrian Hey wrote: > > Jonathan Cast wrote: > > > 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. > > > > You consider real examples from real *standard* libs that we're all > > using (and presumably not written by clueless hackers such as myself) > > to be dogmatic? > > Yeah. Same as if the examples were APIs from ML, or Lisp. The neat > thing about Haskell is *precisely* that the ML I/O system has an API > that is illegal in Haskell. I see no reason, in principle, why the > Haskell standard libraries shouldn't contain APIs that should be illegal > in new-and-improved Future Haskell. > > > I would call that pragmatic myself. These are the > > standard libs after all. Shouldn't we expect them to be the perfect > > examples of how to do things rite? > > > > >> 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? > > > > There's nothing wrong with the APIs as they are as far as I am > > concerned. > > Right. That's exactly what we're arguing about. We maintain they are > inferior. You haven't really given any defense of them at all, other > than their existence. I consider that a rather weak argument. > > > It's their implemenation that's the problem. > > > > > You're advocating an extension to a > > > *purely functional programming language*. > > > > So? What's being proposed doesn't compromise referential transparency > > (at least no more that the IO monad already does, as some might argue). > > What's a referential transparency? I just want a language completely > specified by its denotational semantics, in the obvious fashion (e.g., > (->) maps to an exponential in a real category). > > If IO compromises that (heck, who am I kidding, *since* IO compromises > that), I'm arguing we get rid of whatever features it has that are > questionable. > > > >> 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. > > > > Can't recall expressing any opinion about how stdin should be > > implemented so I don't know what your on about here. > > Well, you didn't like *my* implementation. You seem to be rather keen > on the current implementation GHC happens to use, where stdin contains > internally a mutable buffer. You also seem to be rather insistent that, > whatever mechanism GHC uses to get that mutable buffer, be useable to > create *any other top-level handle* I want. Now, I happen to know that > the only top-level handles that can be established without issuing an > open system call are > > stdin > stdout > stderr > > (unless you're happy to have your global nonStdErr start its life > attached to an unopened FD). I really don't see what your point is, > unless you want to be able to `call open at the top level'. > > On Thu, 2008-08-28 at 22:01 +0100, Adrian Hey wrote: > > Ganesh Sittampalam wrote: > > > On Thu, 28 Aug 2008, Adrian Hey wrote: > > > > > >> implicit parameters (a highly dubious language feature IMO). > > > > > > How can you say that with a straight face at the same time as advocating > > > global variables? :-) > > > > Quite easily, what's the problem? IORefs, Chans etc are perfectly > > ordinary values. Why should they not exist at the top level? > > They aren't the denotations of any closed Haskell expressions. Scarcely > `perfectly ordinary'. > > > The "global variable" lives in "the world", not the IORef. The > > IORef is just a reference, no different from filepaths in principle > > You didn't like my implementation of stdout along those lines, though... > > > (and if having them at the top level is also evil then making this > > so easy and not screaming about it seems a little inconsistent to me). > > Good point. We don't just pretend that filepaths make sense in > themselves, independently of context. (Or would you like to tell me > what the contents of > ~/src/globalscript-0.0.1/Language/GlobalScript/Syntax.lhs are?) In > fact, this mailing list is dedicated to a language that has the radical > idea that you should have to use a whole different type (built using > this scary category-theoretical concept called a `monad') just to > associate filepaths with file contents.
All true. But nevertheless reading it over I think I need to step away from this and cool down a little. jcc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
