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

[Jonathan Cast]

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