[Haskell-cafe] The values of infinite lists
brianh at metamilk.com
Wed May 24 13:45:59 EDT 2006
Paul Hudak wrote:
> Brian Hulley wrote:
>> 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 then you say:
>> and my
>> human experience seems to me to be more than just a deterministic
>> sequential function of Unique -> Time -> SenseInput.
> This seems like a value judgement. Someone else might very much like
> the functional model of things, and might not like some other model.
I see what you mean. Certainly I cannot find any justification for rejecting
the view that one's human experience could indeed be regarded as such a
function, so thanks for correcting me here.
> And one might argue that if the functional view is the same as the
> view that one is using to reason about the rest of the program, then
> that is a Good Thing.
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
2) The functional interpretation of the action thus constructed
1) is accomplished by evaluating main
2) happens secretly afterwards
My current understanding of this is that lazy evaluation allows you to
consider that these two different activities really do happen in the
sequence above, the lazyness just acting as a helpful optimization that
avoids wasting time constructing bits of action that are never going to get
executed (ie lazyness pushes the future back into the present).
Lazyness otherwise seems to be unnecessary as long as >> is always defined
in terms of >>= and never directly by itself, so that the order of function
applications in 2) is fully determined by the data flow in the monad, but I
haven't yet found a definitive explanation of the exact role lazyness plays
in the monadic picture.
> So I'm not saying that there aren't other
> approaches (denotational semantics, operational semantics, process
> calculi, etc.) but they might each have the problem of "understanding
> how it is situated in my own human experience".
I agree. I think it would be good if some tutorials were written also with
these other approaches in mind, so that people who have difficulty
understanding monadic IO from the purely functional perspective would be
able to explore the subject from multiple perspectives and thereby hopefully
find one that situates it properly within their own experience. Also,
someone coming from a non-functional background may initially find it easier
to understand monads given a very low level implementation description eg a
simplified virtual machine interpreted by a C switch statement in a loop
(I'm thinking of Hassan Ait Kaci's excellent WAM reconstruction tutorial for
Prolog), and only later gradually come to understand them from a higher
level point of view.
More information about the Haskell-Cafe