caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Mikkel Fahnøe Jørgensen" <mikkel@dvide.com>
To: "Stéphane Glondu" <steph@glondu.net>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] JIT & HLVM, LLVM
Date: Wed, 30 Sep 2009 21:11:00 +0200	[thread overview]
Message-ID: <caee5ad80909301211r18d32bbbuf3bf56544800b0c2@mail.gmail.com> (raw)
In-Reply-To: <4AC36054.6070704@glondu.net>

2009/9/30 Stéphane Glondu <steph@glondu.net>:
> Mikkel Fahnøe Jørgensen a écrit :
> Actually, I find the typing discipline enforced by the monadic
> abstraction very helpful (and elegant).

For some purposes - for example filtering and transforming large data
sets, but perhaps less so for ad hoc tasks like background reporting -
although of course it can be done.

>> Now, we might as well just push a closure onto a queue instead of on
>> the call stack. This avoid a lot of complexity in the function type
>> design, and we get a lot more flexibility in how we dispatch the tasks
>> (arguably we could do the same or possibly more, in continuation
>> passing style, but it will give you a headache).
>
> This sounds like a narrow (and C-ish) way to tackle things. The bind
> operator is about composition of threads, not scheduling.

Perhaps, but sometimes this makes it easier to get things done,
especially for people not trained in the use of monads. Yes, bind
makes sure that one task is not scheduled at the same time, or before,
another task.

> What you call the "call stack" is orthogonal to your "queues of
> closures": one is about combining results of threaded computations
> whereas the other is just spawning threads and relying on some external
> mechanism to schedule them.

Well - yes and no. In general, monads are about combining results, but
they are also used for thread control where you do not rely on the
results. But it highlights an interesting point: queues does nothing
to help you communicate computation results, in parallel or not.
Neither does a monad based thread library. But a map-reduce monadic
setup very much does combine results and can also be made to schedule
for parallel execution which is very elegant, but not a good match for
more ad-hoc concurrent tasks.

> In other words, I think both can be used together, and achieve different
> purposes.

I agree. It was not my intention to say that monads are bad in any
way, and indeed many of our daily collection types are very useful
monads with abstractions that make them easy to use.

But since monads tend to spread all over the code, I think they should
not be used as a solution to everything, and this is basically what I
meant by "dragging continuations around".

Regards,
Mikkel


  reply	other threads:[~2009-09-30 19:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-27 17:18 David McClain
2009-09-27 17:22 ` [Caml-list] " Vincent Aravantinos
2009-09-27 17:35   ` Edgar Friendly
2009-09-27 18:51     ` Jon Harrop
2009-09-27 19:07       ` Edgar Friendly
2009-09-27 19:23         ` kcheung
2009-09-27 19:33           ` Jon Harrop
2009-09-27 21:10           ` Jon Harrop
2009-09-27 21:45             ` Vincent Aravantinos
2009-09-30  1:08             ` Mikkel Fahnøe Jørgensen
2009-09-30 11:57               ` Stéphane Glondu
2009-09-30 12:54                 ` Mikkel Fahnøe Jørgensen
2009-09-30 13:42                   ` Stéphane Glondu
2009-09-30 19:11                     ` Mikkel Fahnøe Jørgensen [this message]
2009-09-30 15:22               ` Jon Harrop
2009-09-30 19:35                 ` Mikkel Fahnøe Jørgensen
2009-09-28 12:25     ` Gerd Stolpmann
     [not found] <20090927214558.D40C5BC5C@yquem.inria.fr>
2009-09-27 21:59 ` CUOQ Pascal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=caee5ad80909301211r18d32bbbuf3bf56544800b0c2@mail.gmail.com \
    --to=mikkel@dvide.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=steph@glondu.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).