[Haskell-cafe] On the purity of Haskell

AUGER Cédric sedrikov at gmail.com
Thu Dec 29 19:18:18 CET 2011


Le Thu, 29 Dec 2011 01:03:34 +0000,
Steve Horne <sh006d3592 at blueyonder.co.uk> a écrit :

> Sorry for the delay. I've written a couple of long replies already,
> and both times when I'd finished deleting all the stupid stuff there
> was nothing left - it seems I'm so focussed on my own view, I'm
> struggling with anything else today. Maybe a third try...
> 
> On 28/12/2011 19:38, AUGER Cédric wrote:
> > Le Wed, 28 Dec 2011 17:39:52 +0000,
> > Steve Horne<sh006d3592 at blueyonder.co.uk>  a écrit :
> >
> >> This is just my view on whether Haskell is pure, being offered up
> >> for criticism. I haven't seen this view explicitly articulated
> >> anywhere before, but it does seem to be implicit in a lot of
> >> explanations - in particular the description of Monads in SBCs
> >> "Tackling the Awkward Squad". I'm entirely focused on the IO monad
> >> here, but aware that it's just one concrete case of an abstraction.
> 
> > IO monad doesn't make the language impure for me, since you can give
> > another implementation which is perfectly pure and which has the
> > same behaviour (although completely unrealistic):
> 
> > Now how would this work?
> > In a first time, you load all your system file before running the
> > program (a "side-effect" which does not modify already used
> > structures; it is just initialization), then you run the program in
> > a perfectly pure way, and at the end you commit all to the system
> > file (so you modify structures the running program won't access as
> > it has terminated).
> I don't see how interactivity fits that model. If a user provides
> input in response to an on-screen prompt, you can't do all the input
> at the start (before the prompt is delayed) and you can't do all the
> output at the end.

Yes and no, in fact you can think of interactivity as a component of
the environment (you can also tell that "stdin" is the file of what
will be input) and the IO system as causality guardness (ie, you are
not allowed to pick an input before prompting the query).

> 
> Other than that, I'm OK with that. In fact if you're writing a
> compiler that way, it seems fine - you can certainly delay output of
> the generated object code until the end of the compilation, and the
> input done at the start of the compilation (source files) is separate
> from the run-time prompt-and-user-input thing.
> 
> See - I told you I'm having trouble seeing things in terms of someone 
> elses model - I'm back to my current obsession again here.
> > In Haskell,
> > 'hGetChar h>>= \c ->  hPutChar i' always has the same value, but
> > 'trans (hGetChar h>>= \c ->  hPutChar i) (IO_ A)'
> > 'trans (hGetChar h>>= \c ->  hPutChar i) (IO_ B)'
> > may have different values according to A and B.
> >
> > In C, you cannot express this distinction, since you only have:
> > 'read(h,&c, 1); write(i,&c, 1);' and cannot pass explicitely the
> > environment.
> Agreed. Haskell is definitely more powerful in that sense.
> 

There have been a lot of answers in this thread, but I didn't see one
about what I posted:

I encountered a situation where my vision of things was broken:

hGetContents :: Handle -> IO ByteString

in Data.ByteString.Lazy as BS

The following two programs

BS.hGetContents h >>= \b -> close h >> let x = BS.length b in print x
-- ^ Dangerous, never do it!

BS.hGetContents h >>= \b -> let x = BS.length b in close h >> print x
-- ^ The right way to do

is a problem for me, as BS.length doesn't receive an environment as a
parameter, so as they are given the SAME b, they should give the same
result. (For me all BS.ByteString operations should be done inside a
Monad; the non-lazy ByteString doesn't have this problem of course)

***
In fact I am not sure there will be a problem with the "BS.length",
but I had one in a very similar situation, for me the referential
transparency was broken. How to interpret that?

Is it some ugly thing to keep compliant with the non Lazy?
Is it perfectly ok with the semantics, but I misunderstand the
semantics?
Is it some inconsistency nobody thought of? (although I have seen some
very similar comment in this thread)



More information about the Haskell-Cafe mailing list