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<sh006d3...@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.
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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
