Claus Reinke wrote:
[snip]
(the picture is slightly less simple, as 1/2 are repeated, hence
construction and interpretation are interleaved, and later
construction may depend on the results of earlier interpretation, but I
assume you know that;)
This is one of the issues that I was confused
you don't actually need lazyness.
(except if you tried to define directly instead of using = as the
primitive because then the second parameter would be an action directly
instead of a continuation)
yes, you'd want to be non-strict in its second parameter.
Thanks! This is *absolutely* the
I agree with most of your comments Claus. I think that the remaining
difference of opinion is just how much of the I/O semantics one might
expect to see in a textbook on FP (more specifically, Haskell). My
concern is two-fold:
First, to cover ALL of I/O would be an enormous undertaking; at
Points well taken Claus. See further comments below.
Claus Reinke wrote:
Hi Paul,
I think that you're asking for a semantics of the entire OS, i.e. the
entire outside world, and for that I agree that something other than
equational reasoning is needed to reason about it.
I was about to
Brian Hulley wrote:
Paul Hudak wrote:
...
My main point it that if we're reasoning about a single Haskell
program (with no impure features), then the entire world, with all its
non-determinism internal to it, can be modelled as a black box --
i.e. a function -- that interacts with the single
Paul Hudak wrote:
Brian Hulley wrote:
[snip]
So to get back to the question of understanding monads, yes I can
reason about them equationally using pure functions but to
understand Haskell I need to understand how it is situated in my own
human experience ...
I agree with all of this. But
Thanks a lot for your positive reply, Paul. we seem to agree on most
points, or at least understand our different preferences, but there is one
remaining point I'd like to clear up.
Well, in defense of such an approach, there are very few (if any?)
textbooks in ANY language that take a formal
One issue here is that I think there is often not enough clarity about the
two different kinds of functional activity going on ie:
1) The actual construction of the monadic action using = and return (and
fail)
2) The functional interpretation of the action thus constructed
I agree that this
Brian Hulley wrote:
Therefore I humbly submit a call for authors of books/tutorials on IO to
come clean and admit the fact that IO completely changes the language
from being purely functional into a functional + process calculus
language :-)
I agree, but for the completely changes part: the
Hi Claus --
I think that you're asking for a semantics of the entire OS, i.e. the
entire outside world, and for that I agree that something other than
equational reasoning is needed to reason about it. However, I would
argue that that is outside the mandate of a book on Haskell. But maybe
On May 23, 2006, at 9:50 AM, Paul Hudak wrote:
Hi Claus --
I think that you're asking for a semantics of the entire OS, i.e.
the entire outside world, and for that I agree that something other
than equational reasoning is needed to reason about it. However, I
would argue that that is
Robert Dockins wrote:
On May 23, 2006, at 9:50 AM, Paul Hudak wrote:
If you disagree, then please tell me which features in Haskell (a
particular I/O command, perhaps?) cannot be modelled as a function.
IO.hGetContents? I suspect the result of using hGetContents on a file
you have open
Hi Paul,
I think that you're asking for a semantics of the entire OS, i.e. the
entire outside world, and for that I agree that something other than
equational reasoning is needed to reason about it.
I was about to reply no, only of the interface between Haskell and the OS,
but perhaps that
Deokhwan Kim wrote:
Are the values of infinite lists _|_ (bottom)?
Depends on what you mean by value.
If you define value to mean normal form, then yes.
If you define value to mean weak head normal form, then no.
The former is common in strict programming languages. In nonstrict
functional
On Wed, May 10, 2006 at 02:00:20PM +0900, Deokhwan Kim wrote:
To: haskell-cafe@haskell.org
From: Deokhwan Kim [EMAIL PROTECTED]
Date: Wed, 10 May 2006 14:00:20 +0900
Subject: [Haskell-cafe] The values of infinite lists
Are the values of infinite lists _|_ (bottom)?
In section 1.3
Are the values of infinite lists _|_ (bottom)?
No. _|_ represents total lack of information about the result, whereas in a
lazy language like Haskell an infinite list contains a lot of information:
you can observe arbitrary parts of such a list, access them, and compute
with them.
In section
On Wed, 2006-05-10 at 23:29 +0900, Deokhwan Kim wrote:
Bjorn Lisper wrote:
precisely the same as _|_. Only certain kinds of nontermination can be
modeled by _|_ in a non-strict language.
What kinds of nontermination are modeled by _|_ in Haskell?
let f = f in f 3
length [0..]
Duncan
Bjorn Lisper wrote:
Nontermination is not
the precisely the same as _|_. Only certain kinds of nontermination
can be modeled by _|_ in a non-strict language.
What kinds of non-termination are *not* modelled by _|_ in Haskell?
Thanks, Brian.
___
On Wednesday 10 May 2006 12:30 pm, Brian Hulley wrote:
Bjorn Lisper wrote:
Nontermination is not
the precisely the same as _|_. Only certain kinds of nontermination
can be modeled by _|_ in a non-strict language.
What kinds of non-termination are *not* modelled by _|_ in Haskell?
Robert Dockins wrote:
On Wednesday 10 May 2006 12:30 pm, Brian Hulley wrote:
Bjorn Lisper wrote:
Nontermination is not
the precisely the same as _|_. Only certain kinds of nontermination
can be modeled by _|_ in a non-strict language.
What kinds of non-termination are *not* modelled by _|_
On Wednesday 10 May 2006 02:49 pm, you wrote:
Robert Dockins wrote:
On Wednesday 10 May 2006 12:30 pm, Brian Hulley wrote:
Bjorn Lisper wrote:
Nontermination is not
the precisely the same as _|_. Only certain kinds of nontermination
can be modeled by _|_ in a non-strict language.
Deokhwan Kim:
Bjorn Lisper wrote:
precisely the same as _|_. Only certain kinds of nontermination can be
modeled by _|_ in a non-strict language.
What kinds of nontermination are modeled by _|_ in Haskell?
Nonterminating computations that never return anything. For instance,
inf = inf
Björn
Are the values of infinite lists _|_ (bottom)?
In section 1.3, the Haskell 98 report said as follows:
Errors in Haskell are semantically equivalent to _|_. Technically,
they are not distinguishable from nontermination, so the language
includes no mechanism for detecting or acting upon
23 matches
Mail list logo
