Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: clarification on IO (Michael Easter)
2. Re: Defeating type inference (Will Ness)
3. Re: clarification on IO (Chadda? Fouch?)
4. Re: clarification on IO (Gregg Reynolds)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Feb 2009 21:54:24 -0600
From: Michael Easter <[email protected]>
Subject: Re: [Haskell-beginners] clarification on IO
To: Andrew Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Andrew, this is really great...
My main revelation here is that a "side-effect" in other monads is still
pure. e.g. The Logger example in RWH builds up a list of log strings
"behind the scenes" but this is much different than writing to disk, or
launching missiles, to quote SP Jones.
'Revelation' is a good word.... The tectonic plates are coming together! I
needed this.
thanks!
Mike
ps. re: bind/hidden. Monads strike me as a glorious instance of
encapsulation that is not OO, which appropriated the term in the 1990s.
On Fri, Feb 27, 2009 at 9:30 PM, Andrew Wagner <[email protected]>wrote:
> I'll take a shot at answering some of your questions by explaining how I
> understand it, and we'll see if it helps or makes it worse.
>
> Let's talk about monads first. Monads can be thought of as a way of sort of
> hiding "side effects". That is, there is nothing inherently impure about
> monads. The "side effects" happen in the bind function, essentiall. For
> example, in the case of state, the state is carried from one function to
> another. The bind function actually says how to do this; You just don't
> usually see it because it's "hidden" in the do notation. In the Maybe
> function, the plumbing hides the fact that we quit at any point the
> computation fails, and so on. So while in an impure language, any statement
> can have any side effect, in haskell, if you know what monad you're in, you
> know exactly what the "side effect" will occur - which means, it's not
> really a side effect at all, but part of the actual intended effect.
>
> Now for IO. You can think of IO as being essentially State RealWorld. That
> is, every operation is dependent on the entire state of the world, including
> what you're thinking, and what kind of bug is crawling on the 18th blade of
> grass in your yard. If we could actually represent the whole world this way,
> Haskell would truly be a completely pure language. The only reason IO, and
> thus Haskell, is impure at all, is because we can't literally represent the
> whole world. EVERYTHING ELSE, INCLUDING EVERY OTHER TYPE OF MONADIC ACTION
> IN HASKELL, is completely pure.
>
> Ok, so let's address your questions a little more specifically.
>
> Q1: The web page mentions that normal Haskell functions cannot cause
>> side-effects, yet later talks about
>> side-effects with putStrLn. I assume the key point here that IO actions
>> are, by definition, _not_ normal functions?
>>
>
> Right, IO actions can have side effects because they can take into account,
> and modify, the RealWorld.
>
>
>> Q2: Is it true to say that *any* monadic action *could *cause
>> side-effects, depending on the design of that
>> monad? i.e. Does one generalize from the IO monad to (possibly) an
>> arbitrary monad? *Musing* This must be true as
>> using State must surely be considered a side-effect.
>>
>
> Again, yes, this is accurate, but it's different from most impure languages
> in that the side effect is completely baked in by the monad you're in, so
> that you can't really say that the effect is a "side effect" at all.
>
>
>> Q3: The web page mentions IO as being a baton, or token, that is used to
>> thread/order the actions. Is true
>> that this is merely one simple perspective, with respect to order of
>> evaluation? This is hard to articulate,
>> but it seems to me that "in the IO monad" there is a large subsystem of
>> (inaccessible) state, machinery, etc.
>> Is it really a token?
>>
>
> Again, in many ways, it's easier to think of the IO monad as a state monad.
> In that sense, the state of the world is indeed being passed from one action
> to the next, as defined by bind. That's the inaccessible state machinery I
> suspect you're sensing.
>
>
>> Q4: Is the following idea accurate: a Haskell program is partitioned into
>> 2 spaces. One is a sequence
>> of IO actions; the other is a space of pure functions and 'normal' Haskell
>> operations. The execution of a
>> program begins with the main :: IO () action and, effectively, crosses
>> from one space to the other. In the
>> pure space, the math-like functions can be highly optimized but only
>> insofar as they do not disrupt the
>> implied order of the IO actions. Because of the type system, the program
>> recognizes when it enters
>> "back" into the IO space and follows different, less optimized rules.
>>
>
> I think it would be easier to talk about haskell in terms of pure and
> impure code. All Haskell code is pure except for IO. Pure functions are
> easier to reason about and to optimize, because you don't have to take into
> account the RealWorld state, or other possible, REAL side effects..
>
>
>> My concern is that the above is *not* accurate, but I don't know why.
>>
>>
>> thanks so much for your help
>> Michael Easter
>>
>> --
>> ----------------------
>> Michael Easter
>> http://codetojoy.blogspot.com: Putting the thrill back in blog
>>
>> http://youtube.com/ocitv -> Fun people doing serious software engineering
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>
--
----------------------
Michael Easter
http://codetojoy.blogspot.com: Putting the thrill back in blog
http://youtube.com/ocitv -> Fun people doing serious software engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090227/662f4e97/attachment-0001.htm
------------------------------
Message: 2
Date: Sat, 28 Feb 2009 06:50:59 +0000 (UTC)
From: Will Ness <[email protected]>
Subject: [Haskell-beginners] Re: Defeating type inference
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Philip Scott <pscott <at> foo.me.uk> writes:
>
> So I puzzled for a little bit about how to do this in the most Haskelly
> way and I thought of this
>
> months = concat (range (Jan, Dec) : months)
>
> Which should work, right**
>
> ** though I am pretty sure this is the Wrong Way to do this. I suspect
> concat takes O(n) time - more elegant approaches would be welcomed!
>
Nobody seem to relate to that point. No, it's not O(n) time. It's O(1) time.
It's just one lazy definition. The _access_ is O(n) and the definition kicks in
at the right time while riding along with the access - take, drop or whatever -
along the list. It is always just taking one head element at a time off the
first list, if not empty, or else switching to the next one - and feeding that
element to list access. If it's not eliminated completely by compilation. :)
------------------------------
Message: 3
Date: Sat, 28 Feb 2009 10:13:49 +0100
From: Chadda? Fouch? <[email protected]>
Subject: Re: [Haskell-beginners] clarification on IO
To: Michael Easter <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Sat, Feb 28, 2009 at 3:50 AM, Michael Easter <[email protected]> wrote:
> Q1: The web page mentions that normal Haskell functions cannot cause
> side-effects, yet later talks about
> side-effects with putStrLn. I assume the key point here that IO actions are,
> by definition, _not_ normal functions?
putStrLn is a perfectly pure function (there is no other kind in
Haskell), it takes a String and return a value of type IO (), this
value is like any other first class object in Haskell and can be
manipulated as thus, the only difference is that this value can be
computed in the context of the IO monad and then have a side-effect.
The value of type IO a are often called actions but they aren't
fundamentally different from other values.
> Q2: Is it true to say that any monadic action could cause side-effects,
> depending on the design of that
> monad? i.e. Does one generalize from the IO monad to (possibly) an arbitrary
> monad? *Musing* This must be true as
> using State must surely be considered a side-effect.
"Side-effect" isn't really appropriate in my opinion, since everything
is still perfectly pure (except in IO) and the "effects" one obtain by
using a monad are perfectly determined by the nature of the monad.
> Q3: The web page mentions IO as being a baton, or token, that is used to
> thread/order the actions. Is true
> that this is merely one simple perspective, with respect to order of
> evaluation? This is hard to articulate,
> but it seems to me that "in the IO monad" there is a large subsystem of
> (inaccessible) state, machinery, etc.
> Is it really a token?
This "token" is an useful concept to understand how the IO monad
works, indeed that is how it is encoded in GHC where the IO monad is
just a variant of the ST monad with a special type for the state :
RealWorld. Of course the primitives used in the IO monad can't be
written in pure Haskell.
> Q4: Is the following idea accurate: a Haskell program is partitioned into 2
> spaces. One is a sequence
> of IO actions; the other is a space of pure functions and 'normal' Haskell
> operations. The execution of a
> program begins with the main :: IO () action and, effectively, crosses from
> one space to the other. In the
> pure space, the math-like functions can be highly optimized but only insofar
> as they do not disrupt the
> implied order of the IO actions. Because of the type system, the program
> recognizes when it enters
> "back" into the IO space and follows different, less optimized rules.
You can effectively see it like that, but it must be noted that the
ordering of IO actions isn't special in any sense, it is just implied
by the strict data dependence encoded in the monad, the compiler don't
optimize differently the IO portion of the program.
"main" is the only function that is evaluated unconditionally, any
other value and/or function in a program is only evaluated if main
needs it.
--
Jedaï
------------------------------
Message: 4
Date: Sat, 28 Feb 2009 04:30:52 -0600
From: Gregg Reynolds <[email protected]>
Subject: Re: [Haskell-beginners] clarification on IO
To: Michael Easter <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
On Fri, Feb 27, 2009 at 8:50 PM, Michael Easter <[email protected]> wrote:
>
>
> Q1: The web page mentions that normal Haskell functions cannot cause
> side-effects, yet later talks about
> side-effects with putStrLn. I assume the key point here that IO actions
> are, by definition, _not_ normal functions?
>
Right, the IO primitives are not functions.
> Q2: Is it true to say that *any* monadic action *could *cause
> side-effects, depending on the design of that
> monad? i.e. Does one generalize from the IO monad to (possibly) an
> arbitrary monad? *Musing* This must be true as
> using State must surely be considered a side-effect.
>
It might be helpful to distinguish between internal side effects (e.g.
updating a global var in an imperative language) and external (IO). Haskell
uses monads to simulate the former and to serialize the latter.
>
>
> Q3: The web page mentions IO as being a baton, or token, that is used to
> thread/order the actions. Is true
> that this is merely one simple perspective, with respect to order of
> evaluation? This is hard to articulate,
> but it seems to me that "in the IO monad" there is a large subsystem of
> (inaccessible) state, machinery, etc.
> Is it really a token?
>
Bear in mind that's the GHC implementation. I'm told another implementation
uses some kind of continuation monad. The only requirement as I understand
it is that the IO monad, however it is designed, must impose an order of
evaluation on the IO primitives. GHC does hide the implementation details.
>
> Q4: Is the following idea accurate: a Haskell program is partitioned into 2
> spaces. One is a sequence
> of IO actions; the other is a space of pure functions and 'normal' Haskell
> operations. The execution of a
> program begins with the main :: IO () action and, effectively, crosses from
> one space to the other. In the
> pure space, the math-like functions can be highly optimized but only
> insofar as they do not disrupt the
> implied order of the IO actions. Because of the type system, the program
> recognizes when it enters
> "back" into the IO space and follows different, less optimized rules.
>
Hmm, to me there's something fishy about thinking in terms of two spaces.
IO expressions are normal Haskell expressions; they just happen to get
sequenced because they get chained together by monad ops. I.e. as far has
Haskell semantics is concerned they're not special; Haskell needn't know
they're impure. The impure part is external the Haskell semantics. Then
remember lazy evaluation; the whole program can be optimized at compile time
to some extent, and at run time evaluation is forced by the ordering of the
"IO chain" that leads to main.
Be careful about thinking of the program as "starting at main" and then
proceeding through the IO chain. That's perilously close to imperative
thinking. It's more accurate (IMO) to say that the program gets evaluated
at run time, which means main gets evaluated, and since the value of main
depends on the series of IO actions chained to it, they get forced in
order. So main isn't really the "first thing that happens"; it's the ONLY
thing that happens, since the meaning of the program (i.e. main) is
equivalent to the evaluation of the IO chain. Actual IO is a side effect of
evaluating main.
Hope it helps,
gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090228/a3c4a077/attachment.htm
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 8, Issue 30
****************************************
