archives

Preliminary call for participation to MOZ 2004

MOZ 2004 is devoted to bringing together people interested
in the Oz language and the Mozart development platform.
MOZ 2004 will take place in Charleroi, Belgium on October
7-8, 2004. Early registration is possible until August 22.

MOZ 2004 will have two invited speakers (Gert Smolka, the
father of Oz, and Mark Miller, the father of the E secure
distributed language) technical sessions (see the list of
all 23 accepted papers), five tutorials (general overview,
constraint programming, distributed programming, teaching
programming, and tips on practical deployment), and a
panel on the future of Oz. Last but not least, MOZ 2004 is
an excellent opportunity to meet and discuss with the
Mozart designers and other users.

Graham Hutton: Programming in Haskell

The first five chapters of Hutton's introductory Haskell book are online.

The chapters cover fairly basic features, and wouldn't be of interest to the Haskell experts among us, except as teaching material.

However, those intrigued by all the recent references to Haskell can get a taste of what Haskell is about from this readable introduction.

Notes from a Concurrency-Oriented Junkie

Joe Armstrong is at it again in this interesting Erlang-General list discussion, providing a witty yet mind-expanding approach to Erlang program design in Erlang's unique Concurrency Oriented (CO) paradigm:

I always tell people this:

  1. Identify the concurrency in your problem. Give the processes names.
  2. Identify the message channels - give these names.
  3. Write down all the messages that are seen on a channel, give these names

In doing this you have to chose a "granularity of concurrency" that is appropriate for your problem.

If you are modelling crowds then one process per person would be appropriate, you would not model a person as 10^26 molecules with one molecule per processes.

And also

In Concurrency Oriented (CO) programming you concentrate on the concurrency and the messages between the processes. There is no sharing of data.

An Erlang should be thought of thousands of little black boxes all doing things in parallel - these black boxes can send and receive messages. Black boxes can detect errors in other black boxes - that's all.

Ripped from the Erlang List