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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 324D3BC37 for ; Wed, 30 Sep 2009 15:42:45 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.44,480,1249250400"; d="scan'208";a="37179344" Received: from aspirine.inria.fr (HELO [128.93.60.41]) ([128.93.60.41]) by mail1-relais-roc.national.inria.fr with ESMTP; 30 Sep 2009 15:42:45 +0200 Message-ID: <4AC36054.6070704@glondu.net> Date: Wed, 30 Sep 2009 15:42:44 +0200 From: =?UTF-8?B?U3TDqXBoYW5lIEdsb25kdQ==?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: =?UTF-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] JIT & HLVM, LLVM 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> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; mikkel:01 rgensen:01 monadic:01 monadic:01 abstraction:01 orthogonal:01 computations:01 phane:98 steph:98 phane:98 threads:01 threads:01 closures:01 stack:01 stack:01 Mikkel Fahnøe Jørgensen a écrit : > But this requires the function to be designed in a clean way and > conform to certain monadic rules, and getting it wrong creates a mess > in the type errors. Actually, I find the typing discipline enforced by the monadic abstraction very helpful (and elegant). > 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. > More importantly, it is much simpler to understand a closure on a > queue, than continuation passing style. 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. In other words, I think both can be used together, and achieve different purposes. Best regards, -- Stéphane