One popular claim found in litterateur about functional programming is
that programs written in this class of languages is very suitable for
concurrent execution, or interpretation. Due to factors like
referential transparency and the Church-Rosser theorem.

As an outsider I am wondering how concurrency is treated in the
functional world. Is it a major research field, do people think about
it when programming and do the languages offers concurrent features. I
guess this last part exclude Erlang since its so heavily geared
towards concurrency in its core.

And what impact will the, lets call it "the-multi-core-trend" have on
functional programming and programming languages?.

Cheers
-arne

Arne Hanssen wrote:

I've worked on concurrent OCaml and F# applications with great success. The
approaches are quite different but the ability to write in a purely
functional style is hugely beneficial.

Unlike many other languages, functional languages will survive the
transition to multicore.

Jon Harrop jdh30.plus.com> writes:

Cool. Still waiting to find out how. The traditional stuff with
threads and exceptions seems doomed, even using STM.

Paul Rubin wrote:

Well, depends what you're doing, of course, but for IO-bound concurrency
everyone is basically copying Erlang sans the ability to do massive
concurrency. For CPU-intensive concurrency, a few basic thread-based HOFs
are doing me proud.

In article <13jsfa3bf52q419@corp.supernews.com>,
Jon Harrop jdh30.plus.com> wrote:

Can you outline or explain what this difference you encountered is. My
initial thought is that giving the properties of functional programming
concurrency is something that the compiler or the interpreter should be
able to deal with to some extend.

Because?
-arne

Arne Hanssen wrote:

I already blogged it:

http://flyingfrogblog.blogspot.com/2007/07/concurrency.html

I don't think direct compiler support is necessary.

On Nov 16, 5:06 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:

You have to have *some* way of handling mutation, or
else you are limiting the classes of applications you can
write. Any data management application needs some
way to *manage* the data. In that area, transactions*
are the clear winner.

Marshall

PS. Why does it suddenly have to have a three letter
acronym? It's been "transactions" for decades, and now
it's all trendy to call it "STM." Very annoying.

* Marshall:

STM typically has two facilities that traditional transaction processing
lacks, called "retry" and "orElse" in the GHC implementation. "retry"
is a hack which probably doesn't scale that well. "orElse" adds
non-determinism which could be a good ide

* Paul Rubin:

Copy-based message-passing among different processes (= threads with
separate address spaces), for CPU-bound tasks. For mostly-blocking I/O
dispatching, lightweight threads.

I don't know what to do in the case that is bound by per-CPU I/O
bandwidth, this is difficult to parallelize using any method.

Marshall gmail.com> wrote:
[...]

Yeah, that is the current hype. Note that you can implement mutable
ref cells using threads and message passing. In general, if you need
to share a particular data structure, you can make it so that a single
thread owns that data structure and other threads access/update it
through messages sent to that thread. No mutation needed.

-Vesa Karvonen