From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 95224BC37 for ; Wed, 30 Sep 2009 21:11:01 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEDALZJw0rRVdvckGdsb2JhbACRYYhfPwEBAQEJCQwHEwOtZ5AEAQMDBYQiBIgd X-IronPort-AV: E=Sophos;i="4.44,481,1249250400"; d="scan'208";a="33897637" Received: from mail-ew0-f220.google.com ([209.85.219.220]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Sep 2009 21:11:01 +0200 Received: by ewy20 with SMTP id 20so331444ewy.44 for ; Wed, 30 Sep 2009 12:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=iun1y/E25pZtgSTKsG9Dv0MZ8WjLTt8KXSWSlgqBJYw=; b=vKZU6sLrE3Es4FJcgXUsEr1p6SAocBEis0ie3I3PXRWCSWgO3qvCxVUEi8qMr1C3Gv 0YtlADep2EbzN6XpmNqt41GCU8BVg0m4jKC1jGziTFQ6DmAO+DKAglcHkENzIsS5yQvg V8YGIKbokKAunGKGHyKebWpfceEPERI5ZusTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uO6/8pckTKiX9aHIy56tBzlbE3fc0XE1zawAxOxqjjDiKRA4O5+0R+LNqwXMF3we4Q uBvffUxh5nc7oMaxTPUUGCV3ZrOHrOKwb7HAbz62qaLf+H7bOc1bfDiyNYIsY+5SbUZo 4ESOgQs7zPcmtpqELuZx2bO6h16ncBn9Gh3bA= MIME-Version: 1.0 Sender: mikkelfj@gmail.com Received: by 10.216.26.206 with SMTP id c56mr31129wea.209.1254337860594; Wed, 30 Sep 2009 12:11:00 -0700 (PDT) In-Reply-To: <4AC36054.6070704@glondu.net> References: <4E6F3027-5745-462D-AF10-30C868285D28@refined-audiometrics.com> <4ABFB7DE.2050108@gmail.com> <60282.70.26.46.231.1254079393.squirrel@pegasus.carleton.ca> <200909272210.19130.jon@ffconsultancy.com> <4AC34792.8050103@glondu.net> <4AC36054.6070704@glondu.net> Date: Wed, 30 Sep 2009 21:11:00 +0200 X-Google-Sender-Auth: 6cfaba43edfd9614 Message-ID: Subject: Re: [Caml-list] JIT & HLVM, LLVM From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= To: =?UTF-8?Q?St=C3=A9phane_Glondu?= Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; mikkel:01 rgensen:01 mikkel:01 rgensen:01 monadic:01 abstraction:01 transforming:01 monads:01 orthogonal:01 computations:01 monads:01 monadic:01 ad-hoc:01 2009:98 phane:98 2009/9/30 St=C3=A9phane Glondu : > Mikkel Fahn=C3=B8e J=C3=B8rgensen a =C3=A9crit : > 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