Hello Frédéric,

Thank you for the different pointers. I've heard of BSP approach
previously but I'm not up to date with latest news.

2005/6/23, Frédéric Gava <gava@univ-paris12.fr>:
> There is also the fact that you do not develop parallel programs for the
> same things than sequential ones: what is the interest to have a parallel
> language for just an application that play a MP3 ?

Good question that I did not considered when asking my own question.

Right now, I'm writing a user program (with Lablgtk2 user interface)
and a server program (network, file and databases I/O, lot of in
memory data structures, few computation intensive parts, mostly
algorithmic issues). On the user side, I see no real need of
parallelism, except if it can improve responsiveness (e.g. user
graphical front-end and back-end that interact with the server on the
network). On the server side, it is different. If I have a dual core
machine (and *I'm going to have* a 2- or 4-core machine), I would like
my server to reply as fast as possible to clients, which implies that
some tasks must be done in the background, with all the implied
synchronization issues.

As you see, my programmer profile is quite different from the expected
usage of BSMLlib (if I have understood BSMLlib description correctly):
no data parallel programming, rather control parallel programming.

>  Using parallelism is
> good for some specific cases and thus need specifics libraries. Developping
> a "big language" that is good for parallel computing and sequential
> computing seems (it is my opinion) to be a too much harder work.

I'm not interested in THE parallel paradigm that will solve all
parallel programming issues. After 50 years of research, no consensus
have emerged yet.

That's said, it does not mean that OCaml should not provide tools to
improve the current state of affair. It is already doing that with
type inference, GC or sum types. Programming parallel code with Posix
mutexes and threads is a nightmare. I have to say that I had a very
pleasant experiment with OCaml typed channels (aka Concurrent ML
channels). I'm just wondering if INRIA people consider that unknown
(to a wide public) constructs could be offered to ease concurrent
programming. And knowing that current ocaml cannot handle real
concurrent threads is a real concern.

Yours,
david