Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Wolfgang Jeltsch]

Am Donnerstag, 7. Februar 2008 18:33 schrieben Sie:
> Interesting. Thanks for the reply.
>
> It might be nice to have some performance benchmarks for all these
> experimental systems, so we can compare them.

I think, the most important thing is the asymptotical time behavior, e.g., 
whether the time of a certain task is linear, logarithmic or constant in the 
number of widgets.  Constant factors can always be improved.  So performance 
benchmarks don’t seem so important to me in the current early state of FRP 
GUI libraries.

> I could understand that performance might be an issue for games, but for
> GUIs? I mean many imperative GUI systems use rather slow message
> dispatching systems, and we use those every day. Look at the new Windows
> Presentation Foundation system found in VISTA. Here events are broadcasted
> and routed through the whole element tree. This is also rather slow I
> guess.

Are they rooted through every node of the tree (linear time) or are they 
routed down the tree to a leaf (not more than logarithmic time, probably).  
The latter would be acceptable, the former not.  The problem I noted on the 
Grapefruit talk page might result in a Yampa-based GUI taking linear time for 
handling a single event (but I’m not completely sure about that).

Does Vista’s event handling really have linear behavior as your statement 
seems to suggest?

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

Interesting. Thanks for the reply.

It might be nice to have some performance benchmarks for all these experimental 
systems, so we can compare them.

I could understand that performance might be an issue for games, but for GUIs? 
I mean many imperative GUI systems use rather slow message dispatching systems, 
and we use those every day. Look at the new Windows Presentation Foundation 
system found in VISTA. Here events are broadcasted and routed through the whole 
element tree. This is also rather slow I guess. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:haskell-cafe-
> [EMAIL PROTECTED] On Behalf Of Wolfgang Jeltsch
> Sent: Thursday, February 07, 2008 12:25 PM
> To: haskell-cafe@haskell.org
> Subject: Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now
> publicly available
> 
> Hello Peter,
> 
> an answer to an “old” e-mail (from January 25).  Sorry for not
> answering
> earlier.
> 
> Am Freitag, 25. Januar 2008 00:23 schrieben Sie:
> > Wolfgang Jeltsch wrote:
> > > Indeed.  A functional approach to GUIs is nice but at the moment we
> don’t
> > > have anything that is suitable for solving real world problems
> (although
> > > this is being worked on).
> >
> > Could you elaborate a bit on that? What are the current obstacles to
> be
> > solved?
> 
> Performance problems and lack of widgets are the two things that come
> to my
> mind immediately.  Maybe also lack of a good way of doing dynamic user
> interfaces (user interfaces with a changing set/order of widgets).
> 
> > When I looked at Yampa, I didn't really see a problem with making a
> GUI
> > or interactive application based on it (besides maybe performance and
> > space/time leaks, the latter IMO being a general problem in Haskell
> that
> > just occurs quicker in reactive programming).
> 
> I think, performance is a big problem.  To me it seems that Yampa-based
> GUIs
> maybe have a performance penalty of more than just a constant factor.
> Please
> have a look at the sections “Implementation and efficiency” and
> “Signals”
> under <http://haskell.org/haskellwiki/Talk:Grapefruit>.
> 
> > […]
> 
> > The main problem I could see is that Yampa is not really event driven
> in
> > the imperative sense; I mean in an ideal event based system, the
> > hardware triggers an interrupt when some sensor changes, and this
> then
> > triggers other software events; only the code that is related to
> > handling the event that occurred is executed. But the event that is
> > handled could potentially not be needed for the current output (which
> > could be considered as a programming bug...)
> 
> Not necessarily a bug.  There are events which don’t result in changes
> of the
> GUI, for example, mouse clicks into empty areas.
> 
> > […]
> 
> Best wishes,
> Wolfgang
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.21/1263 - Release Date:
> 2/6/2008 8:14 PM


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Wolfgang Jeltsch]

Hello Peter,

an answer to an “old” e-mail (from January 25).  Sorry for not answering 
earlier.

Am Freitag, 25. Januar 2008 00:23 schrieben Sie:
> Wolfgang Jeltsch wrote:
> > Indeed.  A functional approach to GUIs is nice but at the moment we don’t
> > have anything that is suitable for solving real world problems (although
> > this is being worked on).
>
> Could you elaborate a bit on that? What are the current obstacles to be
> solved?

Performance problems and lack of widgets are the two things that come to my 
mind immediately.  Maybe also lack of a good way of doing dynamic user 
interfaces (user interfaces with a changing set/order of widgets).

> When I looked at Yampa, I didn't really see a problem with making a GUI
> or interactive application based on it (besides maybe performance and
> space/time leaks, the latter IMO being a general problem in Haskell that
> just occurs quicker in reactive programming).

I think, performance is a big problem.  To me it seems that Yampa-based GUIs 
maybe have a performance penalty of more than just a constant factor.  Please 
have a look at the sections “Implementation and efficiency” and “Signals” 
under .

> […]

> The main problem I could see is that Yampa is not really event driven in
> the imperative sense; I mean in an ideal event based system, the
> hardware triggers an interrupt when some sensor changes, and this then
> triggers other software events; only the code that is related to
> handling the event that occurred is executed. But the event that is
> handled could potentially not be needed for the current output (which
> could be considered as a programming bug...)

Not necessarily a bug.  There are events which don’t result in changes of the 
GUI, for example, mouse clicks into empty areas.

> […]

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Conal Elliott]

Afaik, you're right about Yampa not being event-driven.  I've been working
on alternatives for a while that are event-driven while still genuinely
functional (non-IO).  See http://haskell.org/haskellwiki/Reactive and
http://haskell.org/haskellwiki/TV .  I have some blog posts in the works
about the inner goings-on of Reactive.

  - Conal

2008/1/24 Peter Verswyvelen <[EMAIL PROTECTED]>:

>  [...]
> The main problem I could see is that Yampa is not really event driven in
> the imperative sense; I mean in an ideal event based system, the hardware
> triggers an interrupt when some sensor changes, and this then triggers other
> software events; only the code that is related to handling the event that
> occurred is executed. But the event that is handled could potentially not be
> needed for the current output (which could be considered as a programming
> bug...) I think Yampa does not do that, it kinda "pulls" the information out
> of the current signal function network, which has the advantage of only
> executing the code that is needed for the output, but the disadvantage is
> that it does a lot of routing and checking which event happened.
>
> Warning to newbies: the above is most likely incorrect information, this
> is just the way I experienced it ;-)
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

Wolfgang Jeltsch wrote:
Indeed.  A functional approach to GUIs is nice but at the moment we don’t have 
anything that is suitable for solving real world problems (although this is 
being worked on).
Could you elaborate a bit on that? What are the current obstacles to be 
solved?


When I looked at Yampa, I didn't really see a problem with making a GUI 
or interactive application based on it (besides maybe performance and 
space/time leaks, the latter IMO being a general problem in Haskell that 
just occurs quicker in reactive programming). I could model state 
machines, dynamic collections, events and event handlers with it, all 
hierarchically. I just would have to practice much much more to get good 
at it. Of course, I'm way too new to functional programming to really 
judge Yampa, it's just the feeling I got from it.


The main problem I could see is that Yampa is not really event driven in 
the imperative sense; I mean in an ideal event based system, the 
hardware triggers an interrupt when some sensor changes, and this then 
triggers other software events; only the code that is related to 
handling the event that occurred is executed. But the event that is 
handled could potentially not be needed for the current output (which 
could be considered as a programming bug...) I think Yampa does not do 
that, it kinda "pulls" the information out of the current signal 
function network, which has the advantage of only executing the code 
that is needed for the output, but the disadvantage is that it does a 
lot of routing and checking which event happened.


Warning to newbies: the above is most likely incorrect information, this 
is just the way I experienced it ;-)


Now IMO the OO way of handling GUIs is also not carved in stone. OO and 
imperative programmers also seem to continue the search for "the best" 
GUI event system. For example, the first version of  the .NET GUI 
"borrowed" the Delphi approach, which was a direct link (through a 
delegate in .NET, called closure in Delphi) between the event source and 
the event listener (in C we know that as a list of (callback,userdata)  
;-) ). Same for QT's signal/slot system. Other systems use a 
producer/dispatcher/consumer pattern (or how is it called). Java AWT 
initially used a message based system, then switched to an interface 
based system. Other systems (like MFC) used a message based approach, 
where the message is routed to many components in a hierarchy. The 
latest version of .NET's GUI system (WPF) again uses such an "element 
tree" and the event can be routed through the whole tree in both 
directions. Some claim Smalltalk's model-view-controller is still the 
best pattern, others claim that the controller is too closely linked to 
the view to be really separate and stick to a document/view model, or 
just duplicate data by using some kind of data-binding... I tried all 
approaches over the last 20 years, and I still see no "best" way...


 :-) The working name for Grapefruit was Vegetables, by the way. ;-) 
LOL! I'll certainly look at it, I find it very fascinating (though 
confusing...) to compare all existing reactive solutions


Thank you,
Peter

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Wolfgang Jeltsch]

Am Mittwoch, 23. Januar 2008 10:53 schrieben Sie:
> Wolfgang Jeltsch wrote:
> > Covering reactive programming would indeed be interesting.
> >
> > I want to add that there is no single way for doing reactive programming
> > in Haskell.  There is Conal’s stuff, there is Yampa and there is “my”
> > stuff (Grapefruit [1]) whereby the pros and cons of these approaches
> > differ.  (And there is plenty of other stuff which doesn’t seem to be
> > actively developed, like, for example, FranTk.)
>
> Doesn't that count for everything? I've been doing imperative & OO
> programming for more than 2 decades, and every technique has its pros
> and cons, it's what makes the job hard, picking the right choices, which
> is (in my case) often more a matter of taste and "it worked before" than
> good reasoning.

Yes, of course.  I just hadn’t recognized that you had also mentioned Yampa, 
and wanted to point out that besides Conal’s stuff there are further 
approaches to reactive programming in Haskell.

> […]

> Gtk2HS can hardly be called pure functional programming can it? It is IO
> and monads everywhere.

Indeed.  A functional approach to GUIs is nice but at the moment we don’t have 
anything that is suitable for solving real world problems (although this is 
being worked on).

> […]

> I haven't looked at Grapefruit yet (actually I don't like fruit, but I
> like vegetables, so lucky me ;-).

The working name for Grapefruit was Vegetables, by the way. ;-) 

> I will certainly do so. Any interesting links?

The most interesting link is  at 
the moment—since it’s the only one. ;-)  Note that, in contrast to the last 
months, this page now links to an up-to-date API documentation.

> Cheers,
> Peter

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Jon Harrop]

On Tuesday 22 January 2008 14:30:22 Bryan O'Sullivan wrote:
> Paul Moore wrote:
> > I'm posting here because there doesn't seem to be an "overall" comment
> > section, but the TOC seems to cover less ground than I expected. Is
> > the TOC meant to be complete?
>
> No, it's less than a third of the whole thing.
>
> Here's the announcement from last May, including a more detailed TOC:
> http://www.realworldhaskell.org/blog/2007/05/23/real-world-haskell-its-time
>
> We've since added a few chapters...

Will there be a chapter on OpenGL?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Dan Weston]

I think this points out the benefit (or even the need), given the 
fast-paced evolution of Haskell and its libraries as a whole, of an 
evolving online supplement to your book, minimally with errata and code, 
but also (as publisher resources permit) with intermittently updated 
appendices on still-evolving technologies and (most risky of all), 
advice on the best tool or library of various tasks (e.g. UI) as a 
function of risk and programmer experience.


I think this approach is the surest defense against shelf-rot.

Dan

Bryan O'Sullivan wrote:

Wolfgang Jeltsch wrote:


Covering reactive programming would indeed be interesting.


I agree.  However, we have no plans to cover this topic.  I don't
believe any of us has used FRP, and my impression of it as an approach
is that it's not yet cooked.  We already have our hands and TOC full
covering well-established topics, never mind tracking the leading edge
of research.  (For similar reasons, we won't be writing about ndp, even
though it's got a lot more obvious crowd appeal.)

http://www.haskell.org/mailman/listinfo/haskell-cafe





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Bryan O'Sullivan]

Wolfgang Jeltsch wrote:

> Covering reactive programming would indeed be interesting.

I agree.  However, we have no plans to cover this topic.  I don't
believe any of us has used FRP, and my impression of it as an approach
is that it's not yet cooked.  We already have our hands and TOC full
covering well-established topics, never mind tracking the leading edge
of research.  (For similar reasons, we won't be writing about ndp, even
though it's got a lot more obvious crowd appeal.)

http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

Wolfgang Jeltsch wrote:

Covering reactive programming would indeed be interesting.

I want to add that there is no single way for doing reactive programming in 
Haskell.  There is Conal’s stuff, there is Yampa and there is “my” stuff 
(Grapefruit [1]) whereby the pros and cons of these approaches differ.  (And 
there is plenty of other stuff which doesn’t seem to be actively developed, 
like, for example, FranTk.)
  
Doesn't that count for everything? I've been doing imperative & OO 
programming for more than 2 decades, and every technique has its pros 
and cons, it's what makes the job hard, picking the right choices, which 
is (in my case) often more a matter of taste and "it worked before" than 
good reasoning.


It would be nice to just briefly introduce the reactive topic and 
available solutions, and let the user know what the advantages and 
disadvantages are of each approach, so he does not reinvent the wheel. 
It is a very interesting domain.


Gtk2HS can hardly be called pure functional programming can it? It is IO 
and monads everywhere. Not that I have something against that (it 
works!), but IMHO it does not offer the same "combinatorial" (?) and 
declarative advantages of the reactive approach, does it? And isn't the 
fact that some of these reactive approaches "blow up" (space/time leaks) 
just a general consequence of Haskell's laziness? You get it more often 
with approaches like FRP, it works a bit better in AFRP (but you still 
have to be careful for leaks). So in imperative languages you get buffer 
overruns, null pointers, dangling pointers, overly eager evaluation, 
side effects depending on evaluation order, etc... In Haskell you can 
get space/time leaks caused by hard to track mutually recursive 
dependencies and unevaluated thunks (I guess). I had it with the former, 
so I'm happy to try the latter and see where it brings me... The more 
people get introduced to this reactive proggy, the better?


Also note that reactive programming in Haskell is not as mature as, for 
instance, GUI programming with Gtk2Hs.  So it might not be wise to add a 
chapter on it now. Maybe in the second version of the book. :-) 
  
Yes but it's not yet robust either. When I made some programs with 
Gtk2HS, I encountered a couple of bugs that I reported (bugs in the GTK 
code on Windows, so nothing to do with Haskell), so what is "mature"?


I haven't looked at Grapefruit yet (actually I don't like fruit, but I 
like vegetables, so lucky me ;-). I will certainly do so. Any 
interesting links?


Cheers,
Peter

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Wolfgang Jeltsch]

Am Dienstag, 22. Januar 2008 15:58 schrieb Peter Verswyvelen:
> Wow, the full TOC looks very impressive indeed! Maybe add a chapter
> about reactive programming (Yampa and Conal's latest stuff that I don't
> understand yet) too? :-)
>
> Cheers,
> Peter

Covering reactive programming would indeed be interesting.

I want to add that there is no single way for doing reactive programming in 
Haskell.  There is Conal’s stuff, there is Yampa and there is “my” stuff 
(Grapefruit [1]) whereby the pros and cons of these approaches differ.  (And 
there is plenty of other stuff which doesn’t seem to be actively developed, 
like, for example, FranTk.)

Also note that reactive programming in Haskell is not as mature as, for 
instance, GUI programming with Gtk2Hs.  So it might not be wise to add a 
chapter on it now. Maybe in the second version of the book. :-) 

Best wishes,
Wolfgang

[1] 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

Wow, the full TOC looks very impressive indeed! Maybe add a chapter 
about reactive programming (Yampa and Conal's latest stuff that I don't 
understand yet) too? :-)


Cheers,
Peter

Bryan O'Sullivan wrote:

Paul Moore wrote:

  

I'm posting here because there doesn't seem to be an "overall" comment
section, but the TOC seems to cover less ground than I expected. Is
the TOC meant to be complete?



No, it's less than a third of the whole thing.

Here's the announcement from last May, including a more detailed TOC:
http://www.realworldhaskell.org/blog/2007/05/23/real-world-haskell-its-time/

We've since added a few chapters, and I wouldn't be surprised if we
subtract a couple in the interests of length later in the process.

http://www.haskell.org/mailman/listinfo/haskell-cafe


  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Paul Moore]

On 22/01/2008, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
>
> > I'm posting here because there doesn't seem to be an "overall" comment
> > section, but the TOC seems to cover less ground than I expected. Is
> > the TOC meant to be complete?
>
> No, it's less than a third of the whole thing.

Ah, that's what I thought. Thanks for the pointer to the full thing -
I'd missed that one.

Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Bryan O'Sullivan]

Paul Moore wrote:

> I'm posting here because there doesn't seem to be an "overall" comment
> section, but the TOC seems to cover less ground than I expected. Is
> the TOC meant to be complete?

No, it's less than a third of the whole thing.

Here's the announcement from last May, including a more detailed TOC:
http://www.realworldhaskell.org/blog/2007/05/23/real-world-haskell-its-time/

We've since added a few chapters, and I wouldn't be surprised if we
subtract a couple in the interests of length later in the process.

http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Paul Moore]

On 21/01/2008, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
> John, Don and I are pleased to announce the beginning of the public beta
> programme for our upcoming book, "Real World Haskell".  For further
> details, please see the following blog entry:
>
> http://www.realworldhaskell.org/blog/2008/01/21/finally-the-public-beta-programme-begins/
>
> Thanks to all of the Haskell community members who have so far performed
> sterling service in commenting on our closed drafts.
>
> We look forward to your feedback!

I'm posting here because there doesn't seem to be an "overall" comment
section, but the TOC seems to cover less ground than I expected. Is
the TOC meant to be complete? In one of the earlier blog postings, you
said you were planning on covering OpenGL, generic programming, web
servers, debugging and profiling. None of these topics seem to have an
obvious plane in the current TOC.

Am I right in expecting the TOC to be expanded as time goes on? What's
there at present seems OK (I haven't read anything in detail yet) but
doesn't seem to cover substantially different ground than the various
other books and tutorials I've seen.

Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Daniel Fischer]

Am Montag, 21. Januar 2008 20:53 schrieb Bryan O'Sullivan:
> John, Don and I are pleased to announce the beginning of the public beta
> programme for our upcoming book, "Real World Haskell".  For further
> details, please see the following blog entry:
>
> http://www.realworldhaskell.org/blog/2008/01/21/finally-the-public-beta-pro
>gramme-begins/
>
> Thanks to all of the Haskell community members who have so far performed
> sterling service in commenting on our closed drafts.
>
> We look forward to your feedback!
>
>   http://book.realworldhaskell.org/beta/, 
what I found reading the first chapter comes this way.

Overall: good style, nice contents.

Operator precedence and associativity:
the ghci command in question (and used in the example box) is :info, not 
:type.

Lists:
range notation: 
"Range notation makes no sense for rational numbers, for example, because 
there is not a countable number of rationals."
There are only countably many rational numbers, and we have
instance (Integral a) => Enum (Ratio a)
(with the same implementation as for Floating point numbers).

The joy of "it":
"When we couple 'it' with liberal use of the arrow keys to recall and edit the 
last expression we typed, and this gives us a fairly decent environment for 
interactive experiments, where the cost of mistakes is very low."

That sentence is broken. One possible fix could be
"We can couple 'it' with liberal use of the arrow keys to recall and edit the 
last expression we typed. This gives us a fairly decent environment for 
interactive experiments where the cost of mistakes is very low."
You can probably do better.

I look forward to buying and reading that book:)

Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

Oops, I just replied to another message asking for such a book!

Amazing that my prayers are answered even before I asked them ;-)

Peter


On Mon, 2008-01-21 at 11:53 -0800, B

ryan O'Sullivan wrote:
> John, Don and I are pleased to announce the beginning of the public beta
> programme for our upcoming book, "Real World Haskell".  For further
> details, please see the following blog entry:
> 
> http://www.realworldhaskell.org/blog/2008/01/21/finally-the-public-beta-programme-begins/
> 
> Thanks to all of the Haskell community members who have so far performed
> sterling service in commenting on our closed drafts.
> 
> We look forward to your feedback!
> 
>___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Bryan O'Sullivan]

John, Don and I are pleased to announce the beginning of the public beta
programme for our upcoming book, "Real World Haskell".  For further
details, please see the following blog entry:

http://www.realworldhaskell.org/blog/2008/01/21/finally-the-public-beta-programme-begins/

Thanks to all of the Haskell community members who have so far performed
sterling service in commenting on our closed drafts.

We look forward to your feedback!

http://www.haskell.org/mailman/listinfo/haskell-cafe