[Haskell-cafe] Re: [Haskell] Top Level <-

Jonathan Cast 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
> 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

> >> 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
`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. 


More information about the Haskell-Cafe mailing list