Lambda the Ultimate

...select the 'View as Text' option on Google Search page.

You probably want install Ghostview. If you are interested in following links to papers from LtU, you should probably get used to postscript.

Actually, the PS file showed only blank pages for me, whereas they're usually no problem, and I had to convert it to a PDF with ps2pdf.

Ghostview opens the file ok here.

sorry for being so obnoxious ;-)

Yeah, the experience of opening the document was pretty painless on my Mac.

(sorry, see my other post below for "on-topic" discussion)

A bit off-topic, but...

http://www.ps2pdf.com/convert/index.htm is good if you only need this sort of thing occasionally.

You can also use Ghostscript to do the same thing.

When you install Ghostscript for Windows, you should get a batch file called 'ps2pdf' with it. (I accepted the defaults and it ended up in "C:\Program Files\gs\gs8.54\lib\").

Then make an environment variable called GSC that holds the full path to gswin32.exe (this file is part of Ghostscript too -- my copy ended up as "c:\Program Files\gs\gs8.54\bin\gswin32.exe"), and create a shortcut to 'ps2pdf' in your 'Send To' folder. You can then easily convert PS files from Windows Explorer from the context menu. The new PDF file ends up in the same folder as the postscript one.

Here's a PDF version. Enjoy, it's good.

Isn't messaging how Erlang handles concurrency?

Specifically, "components processing messages" would be equivalent to "programs processing monads".

If this is what you are talking about--the message-passing model (basically), then yes, ala metaphor:

Basically, if we were to implement a message-passing model, monads would be the data structure that stores "command" or "action" messages.

The Mnesia database in Erlang uses a similar retry strategy but informally relies on the programmer to avoid side-effects in transactions. The practical experience is that some programmers are careful to always do the right thing and others aren't.

The situation in Erlang isn't ideal but I don't think monads and static types would be an appropriate solution there. More realistic would be for side-effects within transactions to cause a runtime exception (crash). I think the important thing is to avoid having incorrect programs that "seem to work" most of the time (like C programs with buffer-overrun vulnerabilities).

I believe you may be confusing the ST monad with the STM monad. The ST monad is used for self-contained stateful computations. Suppose you want to write an imperative GCD function in Haskell for some perverse reason; you could write this monstrosity:

import Control.Monad.ST
import Data.STRef

gcd :: Integer -> Integer -> Integer
gcd a b = runST (imperativeGCD a b)
    where imperativeGCD a b =
            do aRef <- newSTRef a
               bRef <- newSTRef b
               tRef <- newSTRef 0  -- Temporary variable
               gcdLoop aRef bRef tRef
          gcdLoop aRef bRef tRef =
              do a <- readSTRef aRef
                 b <- readSTRef bRef
                 writeSTRef tRef b
                 writeSTRef bRef (a `mod` b)
                 t <- readSTRef tRef
                 writeSTRef aRef t
                 a <- readSTRef aRef
                 b <- readSTRef bRef
                 if (b /= 0) then gcdLoop aRef bRef tRef else return a

The thing about this is that, although it uses an imperative version of Euclid's algorithm, the function gcd is purely functional. That's what the ST monad is for. The STM monad is meant to carry out side-effects on variables that may be shared between threads, and it can't escape the IO monad.

Does that help, or did I misinterpret your post?

Thanks, that clears things up.

I like your "monstruosity" :-)

Haskell seems to be a breeding ground for all kinds of programming concepts, without allowing them to tarnish its elegance. Too bad I still can't reconcile myself with functional-style programs (for more than a few lines). I should really look into a functional syntax that does not bend my head.

There's a comment on the chapter, as well as the Haskell
code and a comparable Erlang version, on this web page:
Solving the Santa Claus Problem in Erlang.

courtesy Richard O'Keefe

BR,
Ulf W

I don't think STM ever claimed to eliminate bugs completely. :)

There's a typo in joinGroup: you're writing the out gate (g2) back to the TVar twice instead of g1 and g2.

http://liyang.hu/crap/Santa.hs