[Haskell-cafe] The values of infinite lists

[Brian Hulley]

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 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 
fail)
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.

Regards, Brian.