Conal Elliott cites Steve Horne:
I look at this World parameter as purely hypothetical, a trick
used to gain an intuition. Whereas Jerzy (I think) uses it to
claim Haskell is referentially transparent - those differing x and
y values come from different worlds, or different
A perhaps acceptable notion of the property we want (purity etc.) is
that all the extensions of the purely functional core language of Haskell
(say the lazy lambda calculus extended with data constructors, etc) are
_conservative_, that is all the equations that hold
in the pure core language
On 02/01/2012 10:03, Jerzy Karczmarczuk wrote:
But I disagree quite strongly with the idea of /World parameter as
purely hypothetical, a trick used to gain an intuition/. I mentioned
the language Clean (no reaction, seems that Haskellians continue to
ignore it...)
I don't know about others,
On 2012/1/1 Ertugrul Söylemez e...@ertes.de wrote:
Steve Horne sh006d3...@blueyonder.co.uk wrote:
Of course even the bind operator arguably isn't primitive. We could
translate to get rid of those too, and see what lies underneath. This
is where we start seeing functions of type...
On Jan 2, 2012, at 1:30 PM, Conal Elliott wrote:
On 2012/1/1 Ertugrul Söylemez e...@ertes.de wrote:
And that's fine, because IO is an embedded DSL. A better view of IO is
a GADT like:
data IO :: * - * where
GetLine :: IO String
PutStrLn :: String - IO ()
...
Chris Smith cdsm...@gmail.com writes:
I wonder: can writing to memory be called a “computational effect”? If
yes, then every computation is impure.
I wonder if not the important bit is that pure computations are unaffected by
other computations (and not whether they can affect other
On Sun, Jan 1, 2012 at 3:26 PM, Ketil Malde ke...@malde.org wrote:
Chris Smith cdsm...@gmail.com writes:
I wonder: can writing to memory be called a “computational effect”? If
yes, then every computation is impure.
I wonder if not the important bit is that pure computations are unaffected by
Dan Doel :
...
Also, the embedded IO language does not have this property.
do x- m ; f x x
is different from
do x- m ; y- m ; f x y
and so on. This is why you shouldn't write your whole program with IO
functions; it lacks nice properties for working with your code.
Sorry, what are
Le Sun, 1 Jan 2012 16:31:51 -0500,
Dan Doel dan.d...@gmail.com a écrit :
On Sun, Jan 1, 2012 at 3:26 PM, Ketil Malde ke...@malde.org wrote:
Chris Smith cdsm...@gmail.com writes:
I wonder: can writing to memory be called a “computational
effect”? If yes, then every computation is impure.
This thread pretty much exemplifies why many people don't bother with this
mailing list anymore.
On Sun, Jan 1, 2012 at 7:00 PM, AUGER Cédric sedri...@gmail.com wrote:
Le Sun, 1 Jan 2012 16:31:51 -0500,
Dan Doel dan.d...@gmail.com a écrit :
On Sun, Jan 1, 2012 at 3:26 PM, Ketil Malde
On 01/01/2012 22:57, Jerzy Karczmarczuk wrote:
Dan Doel :
...
Also, the embedded IO language does not have this property.
do x- m ; f x x
is different from
do x- m ; y- m ; f x y
and so on. This is why you shouldn't write your whole program with IO
functions; it lacks nice
... World - (x, World) ...
I look at this World parameter as purely hypothetical, a trick used to gain
an intuition. Whereas Jerzy (I think) uses it to claim Haskell is
referentially transparent - those differing x and y values come from
different worlds, or different world-states.
I
Steve Horne sh006d3...@blueyonder.co.uk wrote:
The do-notation sugar may confuse the issue - the - looks like an
operator, but translating to binds-and-lambdas form suggests
otherwise. Quick translations (I hope no mistakes) with lots of
parens...
m = (\x - (f x x))
m = (\x - (m =
Steve Horne wrote:
Heinrich Apfelmus wrote:
Maybe it helps to try to find an example of a function f :: A - B
for some cleverly chosen types A,B that is not pure, i.e. does not
return the same values for equal arguments.
[..]
For your specific challenge, place that as a left-hand
Conal Elliott wrote:
I wrote that post to point out the fuzziness that fuels many
discussion threads like this one. See also
http://conal.net/blog/posts/notions-of-purity-in-haskell/ and the
comments.
I almost never find value in discussion about whether language X is
functional, pure, or
On 12/29/2011 07:07 PM, Steve Horne wrote:
On 29/12/2011 10:05, Jerzy Karczmarczuk wrote:
Sorry, a long and pseudo-philosophical treatise. Trash it before reading.
Heinrich Apfelmus:
You could say that side effects have been moved from functions to
some other type (namely IO) in Haskell.
I
On 12/29/2011 11:06 PM, Steve Horne wrote:
On 29/12/2011 21:01, Chris Smith wrote:
On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote:
By definition, an intentional effect is a side-effect. To me, it's by
deceptive redefinition - and a lot of arguments rely on mixing
definitions - but
On 12/29/2011 09:39 PM, Jerzy Karczmarczuk wrote:
Truly random numbers are very rarely used, forget about them.
Well, obviously, but why should we forget about them? The usual
approach(*) is to gather entropy from a truly(**) random source
and use that to seed (and perhaps periodically
On Dec 29, 2011, at 2:16 PM, Steve Horne wrote:
Of course you can extract values out of IO actions to work with them - the
bind operator does this for you nicely, providing the value as an argument to
the function you pass to the right-hand argument of the bind. But that
function returns
Gregg Reynolds d...@mobileink.com писал(а) в своём письме Fri, 30 Dec
2011 17:23:20 +0200:
Regarding side-effects, they can be (informally) defined pretty simply:
any non-computational effect caused by a computation is a side-effect.
I wonder: can writing to memory be called a
On Dec 30, 2011, at 10:34 AM, Artyom Kazak wrote:
Gregg Reynolds d...@mobileink.com писал(а) в своём письме Fri, 30 Dec 2011
17:23:20 +0200:
Regarding side-effects, they can be (informally) defined pretty simply: any
non-computational effect caused by a computation is a side-effect.
On Fri, 2011-12-30 at 18:34 +0200, Artyom Kazak wrote:
I wonder: can writing to memory be called a “computational effect”? If
yes, then every computation is impure. If no, then what’s the difference
between memory and hard drive?
The difference is that our operating systems draw an
On Fri, Dec 30, 2011 at 12:52 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Conal Elliott wrote:
I wrote that post to point out the fuzziness that fuels many
discussion threads like this one. See also http://conal.net/blog/posts/**
On Fri, Dec 30, 2011 at 8:12 AM, Conal Elliott co...@conal.net wrote:
On Fri, Dec 30, 2011 at 12:52 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Conal Elliott wrote:
I wrote that post to point out the fuzziness that fuels many
discussion threads like this one. See also
On Dec 30, 2011, at 10:19 AM, Conal Elliott wrote:
On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The function
f :: Int - IO Int
f x = getAnIntFromTheUser = \i - return (i+x)
is pure according to the common definition of pure in the
On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The function
f :: Int - IO Int
f x = getAnIntFromTheUser = \i - return (i+x)
is pure according to the common definition of pure in
time t: f 42 (computational process implementing func application
begins…)
t+1: keystroke = 1
t+2: 43 (… and ends)
time t+3: f 42
t+4: keystroke = 2
t+5: 44
Conclusion: f 42 != f 42
That conclusion would only follow if the same IO action always produced
the same
On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The function
f :: Int - IO Int
f x = getAnIntFromTheUser = \i - return
Conal Elliott wrote:
Heinrich Apfelmus wrote:
The function
f :: Int - IO Int
f x = getAnIntFromTheUser = \i - return (i+x)
is pure according to the common definition of pure in the context of
purely functional programming. That's because
f 42 = f (43-1) = etc.
Put differently, the
On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The function
On Fri, Dec 30, 2011 at 9:11 AM, Chris Smith cdsm...@gmail.com wrote:
time t: f 42 (computational process implementing func application
begins…)
t+1: keystroke = 1
t+2: 43 (… and ends)
time t+3: f 42
t+4: keystroke = 2
t+5: 44
Conclusion: f 42 != f 42
That
On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams colinpaulad...@gmail.comwrote:
On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
On Fri, Dec 30, 2011 at
On 30 December 2011 17:27, Conal Elliott co...@conal.net wrote:
On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams colinpaulad...@gmail.comwrote:
proof: f is a function, and it is taking the same argument each time.
Therefore the result is the same each time.
Careful of circular reasoning here.
On Fri, Dec 30, 2011 at 9:19 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Conal Elliott wrote:
Heinrich Apfelmus wrote:
The function
f :: Int - IO Int
f x = getAnIntFromTheUser = \i - return (i+x)
is pure according to the common definition of pure in the context of
On Fri, Dec 30, 2011 at 9:30 AM, Colin Adams colinpaulad...@gmail.comwrote:
On 30 December 2011 17:27, Conal Elliott co...@conal.net wrote:
On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams
colinpaulad...@gmail.comwrote:
proof: f is a function, and it is taking the same argument each time.
On Dec 30, 2011, at 11:20 AM, Colin Adams wrote:
On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
On Fri, Dec 30, 2011 at 12:49 AM, Heinrich
On Dec 30, 2011, at 11:11 AM, Chris Smith wrote:
time t: f 42 (computational process implementing func application
begins…)
t+1: keystroke = 1
t+2: 43 (… and ends)
time t+3: f 42
t+4: keystroke = 2
t+5: 44
Conclusion: f 42 != f 42
That conclusion would only
On Fri, Dec 30, 2011 at 9:43 AM, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:20 AM, Colin Adams wrote:
On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
On 30 December 2011 16:59, Gregg Reynolds
On Fri, Dec 30, 2011 at 9:43 AM, Conal Elliott co...@conal.net wrote:
On Fri, Dec 30, 2011 at 9:43 AM, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:20 AM, Colin Adams wrote:
On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:04 AM,
On Dec 30, 2011, at 11:19 AM, Heinrich Apfelmus wrote:
Conal Elliott wrote:
Heinrich Apfelmus wrote:
The function
f :: Int - IO Int
f x = getAnIntFromTheUser = \i - return (i+x)
is pure according to the common definition of pure in the context of
purely functional programming. That's
On 30/12/2011 10:41, Bardur Arantsson wrote:
This doesn't sound right to me. To me, a side effect is something
which happens as a (intended or unintended) consequence of something
else. An effect which you want to happen (e.g. by calling a procedure,
or letting the GHC runtime interpreting
On Dec 30, 2011, at 11:43 AM, Conal Elliott wrote:
roof: f is a function, and it is taking the same argument each time.
Therefore the result is the same each time.
That's called begging the question. f is not a function, so I guess your
proof is flawed.
It seems pretty clear that
Quoth Steve Horne sh006d3...@blueyonder.co.uk,
On 30/12/2011 10:41, Bardur Arantsson wrote:
This doesn't sound right to me. To me, a side effect is something
which happens as a (intended or unintended) consequence of something
else. An effect which you want to happen (e.g. by calling a
On Dec 30, 2011, at 11:21 AM, Conal Elliott wrote:
And I also raised a more fundamental question than whether this claim of
sameness is true, namely what is equality on IO? Without a precise
consistent definition of equality, the claims like f 42 == f (43 - 1) are
even defined, let
On Fri, Dec 30, 2011 at 10:24 AM, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:43 AM, Conal Elliott wrote:
roof: f is a function, and it is taking the same argument each time.
Therefore the result is the same each time.
That's called begging the question. f is not a
On 30/12/2011 15:23, Gregg Reynolds wrote:
Now one way of understanding all this is to say that it implicates the
static/dynamic (compile-time/run-time) distinction: you don't know what e.g. IO
values are until runtime, so this distinction is critical to distinguishing
between pure and
On Fri, Dec 30, 2011 at 10:45 AM, Gregg Reynolds d...@mobileink.com wrote:
On Dec 30, 2011, at 11:21 AM, Conal Elliott wrote:
And I also raised a more fundamental question than whether this claim of
sameness is true, namely what is equality on IO? Without a precise
consistent definition
On 30/12/2011 15:50, Gregg Reynolds wrote:
On Dec 30, 2011, at 10:34 AM, Artyom Kazak wrote:
Gregg Reynoldsd...@mobileink.com писал(а) в своём письме Fri, 30 Dec 2011
17:23:20 +0200:
Regarding side-effects, they can be (informally) defined pretty simply: any
non-computational effect
On Fri, 2011-12-30 at 12:45 -0600, Gregg Reynolds wrote:
I spent some time sketching out ideas for using random variables to provide
definitions (or at least notation) for stuff like IO. I'm not sure I could
even find the notes now, but my recollection is that it seemed like a
promising
Donn Cave d...@avvanta.com писал(а) в своём письме Fri, 30 Dec 2011
20:36:46 +0200:
That's why we use terms in a sense that apply meaningfully to computer
programming languages in general and Haskell in particular. To do
otherwise - for example to insist on a definition of pure that could
On Fri, 2011-12-30 at 12:24 -0600, Gregg Reynolds wrote:
No redefinition involved, just a narrowing of scope. I assume that,
since we are talking about computation, it is reasonable to limit the
discussion to the class of computable functions - which, by the way,
are about as deeply embedded
Chris Smith cdsm...@gmail.com писал(а) в своём письме Fri, 30 Dec 2011
22:04:21 +0200:
Computability is just a distraction here. The problem isn't whether
getAnIntFromUser is computable... it is whether it's a function at
all! Even uncomputable functions are first and foremost functions,
On Fri, 2011-12-30 at 23:16 +0200, Artyom Kazak wrote:
Thus, your function “f” is a function indeed, which generates a list of
instructions to kernel, according to given number.
Not my function, but yes, f certainly appears to be a function.
Conal's concern is that if there is no possible
On 2011-12-30 14:32, Steve Horne wrote:
A possible way to implement a Haskell program would be...
1. Apply rewrite rules to evaluate everything possible without
executing primitive IO actions.
2. Wait until you need to run the program.
3. Continue applying rewrite rules to evaluate
Chris Smith cdsm...@gmail.com писал(а) в своём письме Fri, 30 Dec 2011
22:28:36 +0200:
I really think that the notion of “purity” appeared to convince C
programmers. It would be silly to try to explain that “Int - IO Int”
isn't really a function from Int to Int, monads, blah blah blah. So,
On 30/12/2011 10:47, Bardur Arantsson wrote:
On 12/29/2011 11:06 PM, Steve Horne wrote:
Using similar mixed definitions to conclude that every C program is full
of bugs (basically equating intentional effects with side-effects, then
equating side-effects with unintentional bugs) is a fairly
On 30/12/2011 20:38, Scott Turner wrote:
On 2011-12-30 14:32, Steve Horne wrote:
A possible way to implement a Haskell program would be...
1. Apply rewrite rules to evaluate everything possible without
executing primitive IO actions.
2. Wait until you need to run the program.
3.
On 12/30/2011 10:10 PM, Steve Horne wrote:
On 30/12/2011 10:47, Bardur Arantsson wrote:
On 12/29/2011 11:06 PM, Steve Horne wrote:
Calling it a straw man won't convince anyone who has the scars from
being attacked by those straw men.
I've been in those arguments, being told that C has
Steve Horne wrote:
Heinrich Apfelmus wrote:
Purity has nothing to do with the question of whether you can express
IO in Haskell or not.
The beauty of the IO monad is that it doesn't change anything about
purity. Applying the function
bar :: Int - IO Int
to the value 2 will
Sorry, a long and pseudo-philosophical treatise. Trash it before reading.
Heinrich Apfelmus:
You could say that side effects have been moved from functions to some
other type (namely IO) in Haskell.
I have no reason to be categorical, but I believe that calling the
interaction of a Haskell
On 29/12/2011 08:48, Heinrich Apfelmus wrote:
Steve Horne wrote:
Heinrich Apfelmus wrote:
Purity has nothing to do with the question of whether you can
express IO in Haskell or not.
The beauty of the IO monad is that it doesn't change anything about
purity. Applying the function
On Dec 29, 2011, at 9:16 AM, Donn Cave wrote:
Quoth Gregg Reynolds d...@mobileink.com,
On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The beauty of the IO monad is that it doesn't change anything about purity.
Applying the function
bar :: Int - IO
On 29/12/2011 18:04, Donn Cave wrote:
Quoth Steve Hornesh006d3...@blueyonder.co.uk,
...
Anyway, if you're using IO actions, your code is not referentially
transparent and is therefore impure - by your own definition of
impure. Causing side-effects may not be pedantically the issue, but
the mix
On 29/12/2011 18:41, Chris Smith wrote:
Entering tutorial mode here...
On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote:
We can talk endlessly about what your external/execution results
might be for some IO action, but at the formulaic level of a Haskell
program it's a simple function value,
Gregg Reynolds wrote:
Donn Cave wrote:
Quoth Gregg Reynolds wrote:
Look again at the sentence you trimmed off the end:
Of course, the point is that this result is an *IO action* of
type IO Int, it's not the Int you would get when executing
this action.
I believe that more or less points
Quoth Steve Horne sh006d3...@blueyonder.co.uk,
On 29/12/2011 08:48, Heinrich Apfelmus wrote:
...
Well, it's a matter of terminology: impure /= has side effects.
The ability of a language to describe side effects is not tied to its
(im)purity.
Again, purity refers to the semantics of
Quoth Gregg Reynolds d...@mobileink.com,
On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The beauty of the IO monad is that it doesn't change anything about purity.
Applying the function
bar :: Int - IO Int
to the value 2 will always give the same
Steve Horne wrote:
Heinrich Apfelmus wrote:
Again, purity refers to the semantics of functions (at run-time):
given the same argument, will a function always return the same
result? The answer to this question solely decides whether the
language is pure or impure. Note that this depends on
On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The beauty of the IO monad is that it doesn't change anything about purity.
Applying the function
bar :: Int - IO Int
to the value 2 will always give the same result:
bar 2 = bar (1+1) = bar (5-3)
Quoth Steve Horne sh006d3...@blueyonder.co.uk,
On 29/12/2011 18:41, Chris Smith wrote:
...
On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote:
We can talk endlessly about what your external/execution results
might be for some IO action, but at the formulaic level of a Haskell
program it's a
On Dec 29, 2011, at 11:29 AM, Antoine Latter wrote:
On Thu, Dec 29, 2011 at 11:14 AM, Gregg Reynolds d...@mobileink.com wrote:
On Dec 29, 2011, at 11:01 AM, Iustin Pop wrote:
And to clarify better my original email: yes, (bar x) always gives you
back the same IO action;
More
29.12.2011, 23:55, Gregg Reynolds d...@mobileink.com:
Haskell does not and cannot know what the result of an IO action is, because
it's outside the scope of the language (and computation). (The Int part of
IO Int refers to the input, not the output; it's just a sort of type
On Thu, Dec 29, 2011 at 11:14 AM, Gregg Reynolds d...@mobileink.com wrote:
On Dec 29, 2011, at 11:01 AM, Iustin Pop wrote:
And to clarify better my original email: yes, (bar x) always gives you
back the same IO action;
More precisely: the same *type*.
I'm confused - what do you mean by
Here's an alternative perspective to consider: consider some
data structure, such as a queue. There are two ways you can
implement this, one the imperative way, with mutators, and the
other the purely functional way, with no destructive updates.
The question then, I ask, is how easy does a
Le 29/12/2011 18:01, Iustin Pop a écrit :
I'm confused as what you mean.
And to clarify better my original email: yes, (bar x) always gives you
back the same IO action; but the results of said IO action are/can be
different when executed.
The whole of my point is that it DOESN'T MATTER. (And I
On Thu, Dec 29, 2011 at 05:51:57PM +0100, Jerzy Karczmarczuk wrote:
Iustin Pop::
In practice too:
bar _ = do
s- readFile /tmp/x.txt
return (read s)
Once you're in a monad that has 'state', the return value doesn't
strictly depend anymore on the function arguments.
Nice example.
On 29/12/2011 19:21, Heinrich Apfelmus wrote:
Why would IO Int be something special or mysterious? It's an
ordinary value like everything else; it's on the same footing as
[Char], Maybe Int, Int - String, Bool, and so on. I see no difference
between the list [1,2,3] :: [Int] and the
Of course we take in matter what computation getStr :: IO [Char] means.
Of course we take in matter what computation putStr :: String - IO () means
(I know, putStr is not computation, puStr x is computation, but it's not
important)
And If I want to write echo program, I have to combine these
Quoth Gregg Reynolds d...@mobileink.com,
..
A minor point maybe, but germane to the original post (I hope).
It isn't - I mean, I'm not really sure what your point is, but
the example really returns the same IO value, not just one of
the same type.
Consider an example with implementation:
On Thu, Dec 29, 2011 at 05:55:24PM +0100, Iustin Pop wrote:
On Thu, Dec 29, 2011 at 05:51:57PM +0100, Jerzy Karczmarczuk wrote:
Iustin Pop::
In practice too:
bar _ = do
s- readFile /tmp/x.txt
return (read s)
Once you're in a monad that has 'state', the return value
On Dec 29, 2011, at 11:01 AM, Iustin Pop wrote:
On Thu, Dec 29, 2011 at 05:55:24PM +0100, Iustin Pop wrote:
On Thu, Dec 29, 2011 at 05:51:57PM +0100, Jerzy Karczmarczuk wrote:
Iustin Pop::
In practice too:
bar _ = do
s- readFile /tmp/x.txt
return (read s)
Once you're in a monad
Le Thu, 29 Dec 2011 01:03:34 +,
Steve Horne sh006d3...@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
Entering tutorial mode here...
On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote:
We can talk endlessly about what your external/execution results
might be for some IO action, but at the formulaic level of a Haskell
program it's a simple function value, e.g., IO Int.
Not to nitpick, but I'm
On 29/12/2011 10:05, Jerzy Karczmarczuk wrote:
Sorry, a long and pseudo-philosophical treatise. Trash it before reading.
Heinrich Apfelmus:
You could say that side effects have been moved from functions to
some other type (namely IO) in Haskell.
I have no reason to be categorical, but I
Iustin Pop::
In practice too:
bar _ = do
s- readFile /tmp/x.txt
return (read s)
Once you're in a monad that has 'state', the return value doesn't
strictly depend anymore on the function arguments.
Nice example. PLEASE, show us the trace of its execution. Then, the
discussion might be
On Thu, Dec 29, 2011 at 07:19:17AM -0600, Gregg Reynolds wrote:
On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
The beauty of the IO monad is that it doesn't change anything about purity.
Applying the function
bar :: Int - IO Int
to the value 2
If seed depends of psudo random event, for example of current systime,
we must use IO action.
30.12.2011, 02:47, Steve Horne sh006d3...@blueyonder.co.uk:
BTW - why use an IO action for random number generation? There's a
perfectly good pure generator. It's probably handy to treat it
On 12/29/2011 08:47 PM, Steve Horne wrote:
On 29/12/2011 19:21, Heinrich Apfelmus wrote:
BTW - why use an IO action for random number generation? There's a
perfectly good pure generator. It's probably handy to treat it
monadically to sequence the generator state/seed/whatever but random
On Dec 29, 2011, at 12:33 PM, Donn Cave wrote:
Quoth Gregg Reynolds d...@mobileink.com,
..
A minor point maybe, but germane to the original post (I hope).
It isn't - I mean, I'm not really sure what your point is, but
the example really returns the same IO value, not just one of
the same
On 29/12/2011 19:26, Heinrich Apfelmus wrote:
Steve Horne wrote:
Heinrich Apfelmus wrote:
Again, purity refers to the semantics of functions (at run-time):
given the same argument, will a function always return the same
result? The answer to this question solely decides whether the
On Dec 29, 2011, at 1:21 PM, Heinrich Apfelmus wrote:
Why would IO Int be something special or mysterious?
I don't know if it is special or mysterious, but I'm pretty sure IO is
non-deterministic, non-computable, etc. In other words not the same as
computation.
It's an ordinary value
On 29/12/2011 19:55, Bardur Arantsson wrote:
On 12/29/2011 08:47 PM, Steve Horne wrote:
On 29/12/2011 19:21, Heinrich Apfelmus wrote:
BTW - why use an IO action for random number generation? There's a
perfectly good pure generator. It's probably handy to treat it
monadically to sequence the
The story begins here:
Steve Horne:
/BTW - why use an IO action for random number generation? There's a
perfectly good pure generator. It's probably handy to treat it
monadically to sequence the generator state/seed/whatever but random
number generation can be completely pure. /
On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote:
By definition, an intentional effect is a side-effect. To me, it's by
deceptive redefinition - and a lot of arguments rely on mixing
definitions - but nonetheless the jargon meaning is correct within
programming and has been for decades.
On 29/12/2011 20:39, Jerzy Karczmarczuk wrote:
Still, I dont understand what does S.H. mean by a perfectly good
pure generator.
Tell more please (unless you just mean a stream, say:
Probably bad wording, to be honest. I only meant that there's random
number handling support in the Haskell
On Thu, 2011-12-29 at 21:04 +, Steve Horne wrote:
AFAIK there's no hidden unsafePerformIO sneaking any entropy in behind
the scenes. Even if there was, it might be a legitimate reason for
unsafePerformIO - random numbers are in principle non-deterministic,
not determined by the current
Steve Horne :
I only meant that there's random number handling support in the
Haskell library and, and least judging by type signatures, it's pure
functional code with no hint of the IO monad.
Look well at those functions, please.
Within the RandomGen class you have pure members, such as next
On 29/12/2011 21:01, Chris Smith wrote:
On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote:
By definition, an intentional effect is a side-effect. To me, it's by
deceptive redefinition - and a lot of arguments rely on mixing
definitions - but nonetheless the jargon meaning is correct within
On 29/12/2011 21:51, Jerzy Karczmarczuk wrote:
Steve Horne :
I only meant that there's random number handling support in the
Haskell library and, and least judging by type signatures, it's pure
functional code with no hint of the IO monad.
Look well at those functions, please.
Challenge
On 2011-12-29 15:23, Gregg Reynolds wrote:
On Dec 29, 2011, at 1:21 PM, Heinrich Apfelmus wrote:
Why would IO Int be something special or mysterious?
I'm pretty sure IO is non-deterministic, non-computable, etc. In other words
not the same as computation.
It's an ordinary value like
1 - 100 of 126 matches
Mail list logo
