The main change I would make is to rename the arguments to
client/server; they overload the same names (reqs/resps) as the top
level declarations above, so it's very easy to get confused while
reading it.
Partially, I think this is just a hard concept to understand;
struggling to figure it out def
2009/5/28 Petr Pudlak :
> Hi Ryan, thanks for a nice and thorough explanation. I had trouble
> understanding the section of the tutorial as well. Maybe it would deserve to
> rewrite to something a bit simpler?
>
> Anyhow, I'd like to ask: Is there a reason for which pattern matching for
> single-co
Hi Ryan, thanks for a nice and thorough explanation. I had trouble
understanding the section of the tutorial as well. Maybe it would deserve to
rewrite to something a bit simpler?
Anyhow, I'd like to ask: Is there a reason for which pattern matching for
single-constructor data types isn't lazy by
张旭 writes:
> Hi, I am really new to haskell. I am reading "A gentle instruction
> to haskell" now. And I just cannot understand the chapter below. Is
> there anybody who can gives me some hints about why the pattern
> matching for "client" is so early? How does the pattern matching
> works here?
Hi nemo. I had a lot of trouble with that section of the tutorial as
well, and I believe that once you get it, a lot of Haskell becomes a
lot simpler.
The way I eventually figured it out is using this idealized execution
model for Haskell: you just work by rewriting the left side of a
function to
Hello 张旭,
Wednesday, May 27, 2009, 11:51:34 PM, you wrote:
> Hi, I am really new to haskell. I am reading "A gentle instruction
> to haskell" now. And I just cannot understand the chapter below. Is
> there anybody who can gives me some hints about why the pattern
> matching for "client" is so ear