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

[Jonathan Cast]

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. 

jcc