Excerpts from Jason Dusek's message of Sun May 17 15:45:25 +0200 2009:
> From the documentation:
>
> " LI could be a strict monad and a strict applicative functor.
> However it is not a lazy monad nor a lazy applicative
> functor as required Haskell. Hopefully it is a lazy
> (point
From the documentation:
" LI could be a strict monad and a strict applicative functor.
However it is not a lazy monad nor a lazy applicative
functor as required Haskell. Hopefully it is a lazy
(pointed) functor at least.
I'd like to understand this better -- how is LI incompatib
-io package [1] that does exactly this
and is going to be explained and motivated in the rest of this post.
=== The context ===
Although these times were hard with the Lazy/IO technique, some people continue
to defend them arguing that all discovered problems about it was not that
harmful
and that
Lennart Augustsson wrote:
I don't see any breaking of referential transparence in your code.
Every time you do an IO operation the result is basically
non-deterministic since you are talking to the outside world.
You're assuming the IO has some kind of semantics that Haskell makes
no promises abo
eaved with unsafeInterleaveIO such that we see the
results we do (even though we know that isn't what's going on operationally;
it isn't what's going on operationally with concurrency, either).
The real issue is that lazy IO sometimes leads people to write buggier
programs tha
IO (more on it below). The message posted yesterday exhibited a
> context C[] that distinguishes f1 from f2. Thus, in presence of Lazy
> IO, any equational theory that equates f1 and f2 cannot be sound. I
> don't think one can design such a context C[] using the regular, eager
&g
e. As was shown
> yesterday, with Lazy IO, Haskell is not pure.
>
> Before we discuss definitions, let us note the motivations. Suppose I
> have a Haskell program. As every single (compiled) Haskell program it
> has the main function, of the type IO a for some a. It must use IO, at
> lea
regular file (stream) IO_ is pure. As was shown
> yesterday, with Lazy IO, Haskell is not pure.
>
> Before we discuss definitions, let us note the motivations. Suppose I
> have a Haskell program. As every single (compiled) Haskell program it
> has the main function, of the type IO a
As Amr Sabry aptly observed more than a decade ago discussions of
purity and referential transparency usually lead to confusion and
disagreement. His JFP paper provided the needed rigor and argued that
Haskell even _with regular file (stream) IO_ is pure. As was shown
yesterday, with Lazy IO
l proof that unsafeInterleaveIO cannot break RT,
> but I've not seen an example where it does yet.)
>
> -- Lennart
>
> On Thu, Mar 5, 2009 at 2:12 AM, wrote:
>>
>>
>> We demonstrate how lazy IO breaks referential transparency. A pure
>> function
- Lennart
On Thu, Mar 5, 2009 at 2:12 AM, wrote:
>
>
> We demonstrate how lazy IO breaks referential transparency. A pure
> function of the type Int->Int->Int gives different integers depending
> on the order of evaluation of its arguments. Our Haskell98 code uses
> noth
On Wednesday 04 March 2009 9:12:20 pm o...@okmij.org wrote:
> We demonstrate how lazy IO breaks referential transparency. A pure
> function of the type Int->Int->Int gives different integers depending
> on the order of evaluation of its arguments. Our Haskell98 code uses
&g
On Wed, 2009-03-04 at 18:22 -0800, Jonathan Cast wrote:
> On Wed, 2009-03-04 at 18:12 -0800, o...@okmij.org wrote:
> >
> > We demonstrate how lazy IO breaks referential transparency. A pure
> > function of the type Int->Int->Int gives different integers depending
>
On Wed, 2009-03-04 at 18:12 -0800, o...@okmij.org wrote:
>
> We demonstrate how lazy IO breaks referential transparency. A pure
> function of the type Int->Int->Int gives different integers depending
> on the order of evaluation of its arguments. Our Haskell98 code uses
We demonstrate how lazy IO breaks referential transparency. A pure
function of the type Int->Int->Int gives different integers depending
on the order of evaluation of its arguments. Our Haskell98 code uses
nothing but the standard input. We conclude that extolling the purity
of Haske
On 19 April 2005 06:30, Johannes Waldmann wrote:
> Thanks for the comments. Indeed I knew the solution -
> once I isolated the problem.
>
> Note that ghc(i) behaves differently when running main2 below
> (it says "file is locked"). (hugs does not complain.)
>
> import System
>
> main1 = do
>
Thanks for the comments. Indeed I knew the solution -
once I isolated the problem.
Note that ghc(i) behaves differently when running main2 below
(it says "file is locked"). (hugs does not complain.)
import System
main1 = do
system "echo A > foo"
a <- readFile "foo"
system "echo B > foo"
> Well, not quite. ($!) (like `seq`, out of which it's built) forces
> evaluation only to "weak head normal form": essentially enough to
> determine the top-level constructor. Here, for String, that means
> only the first character need be evaluated, which in practice means
> only the first buffe
At 10:11 PM -0400 4/18/05, Cale Gibbard wrote:
The action readFile is a bit unsafe in that it does lazily interleaved
IO -- that is, the file is read as you consume the string, and only
the part of the string which you use will be read from the file -- if
the file is 10G, but you only end up needin
The action readFile is a bit unsafe in that it does lazily interleaved
IO -- that is, the file is read as you consume the string, and only
the part of the string which you use will be read from the file -- if
the file is 10G, but you only end up needing the first 100K of it, or
only need to consume
it took me quite a while to isolate the following.
what does this program print? certainly "A"
(written by the first system call) is different from "B"?
import System
main = do
system "echo A > foo"
a <- readFile "foo"
system "echo B > foo"
b <- readFile "foo"
print (a == b)
bes
ata DirTree = DirTree File [DirTree]
>
> but then I apparently need lazy IO. If lazy IO is bad, is
>
> data DirTree = DirTree File [IO DirTree]
>
> a better way of doing it?
Hard to say. In this case, lazy io doesn't seem to bad, to me at
least. but keep in mind that
On Sat, 18 Oct 2003 19:17:06 -0700 (PDT) Hal Daume III <[EMAIL PROTECTED]> wrote:
> It is unsafe because, in general, lazy IO is a bad idea. In particular:
>
> foo f x = do
> h <- openFile x ReadMode
> t <- hGetContents h
> v <- f t
> hClose h
>
It is unsafe because, in general, lazy IO is a bad idea. In particular:
foo f x = do
h <- openFile x ReadMode
t <- hGetContents h
v <- f t
hClose h
return t
will do substantially different things depending on the strictness of
'f'. For instance, if 'f'
On Sun, 19 Oct 2003 02:03:58 +0200 Nick Name <[EMAIL PROTECTED]> wrote:
> You have to use unsafeInterleaveIO, wich lazily defers the IO action
> passed as an argument. Look for this function in your documentation,
> both hugs and ghc have it.
Got it, thanks. Do you know in what sense it is "uns
Alle 01:50, domenica 19 ottobre 2003, Ben Escoto ha scritto:
> which only reads one character. So how do you write getContents in
> haskell? Thanks for any insight.
You have to use unsafeInterleaveIO, wich lazily defers the IO action
passed as an argument. Look for this function in your documen
Hi, I'm trying to do IO and it isn't lazy enough. My problem seems
similar to this one: Write a function that lazily reads characters
from stdin, just like getContents does. These two don't work:
lazyRead :: IO String
lazyRead = do first_char <- getChar
rest <- lazyRea
On Tue, 3 Sep 2002 20:08:32 +0100
"Duncan Coutts" <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Sep 2002 14:49:45 -0400
> [EMAIL PROTECTED] wrote:
>
> > Is there any way to make the IO Monad lazy?
> >
> > The simplified version of my problem is that I want to
> > generate an infinite structure from an
On Tue, 3 Sep 2002 14:49:45 -0400
[EMAIL PROTECTED] wrote:
> Is there any way to make the IO Monad lazy?
>
> The simplified version of my problem is that I want to
> generate an infinite structure from an IOArray and then
> consume only the relevant part of it.
Yes, unsafeInterleaveIO.
http://
Is there any way to make the IO Monad lazy?
The simplified version of my problem is that I want to
generate an infinite structure from an IOArray and then
consume only the relevant part of it.
The real version of my problem is that the IOArray is
embedded 4 API layers deep and it would be a lot
30 matches
Mail list logo
