[Haskell-cafe] Re: [Haskell] Top Level <-
jonathanccast at fastmail.fm
Thu Aug 28 17:45:14 EDT 2008
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
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
> >> 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
(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
> 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.
More information about the Haskell-Cafe