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.5 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 686CCBBCA for ; Fri, 9 May 2008 08:31:16 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvACAL6MI0jRVcbuc2dsb2JhbACCNTaPGwEMAwQECQ+TMoVa X-IronPort-AV: E=Sophos;i="4.27,459,1204498800"; d="scan'208";a="25986700" Received: from rv-out-0506.google.com ([209.85.198.238]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 May 2008 08:31:15 +0200 Received: by rv-out-0506.google.com with SMTP id f6so1206909rvb.3 for ; Thu, 08 May 2008 23:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=xdMpM6OyqYnNwMLlYzDqYBiX5tS0g1bDgw1Wt22AVZk=; b=g4z7GFZzFJ83DZgBPv32vKGOA17Hi91MGAL15OyoqpofyGbEL2jiJpEnHj5+pBNDqCgle2yXGvRaZi2UXDGByTiuGrZgrRj1UHM2+05W0H/nQEHbbPidQpB3vqcPFE3m4qAujb3zSIXdCzoxep2vHA+14X2iW/k7TLiO1kVP/2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jm1cH5p3F/U43YHcEDprMss4k5E0c+O4ihYZ0JT+zDHRQL45OVKfX+Z2W0r/vZrQ9cRKmJadtyqKdFy2wdJFcJq5h1r1d4hAwVXgfW2KIG3NtBtBnvUVLXv2UwRGQPIWe2AvMOiIW2kpJqciSLrdSryBs9iBIhkGTqrv2uDJFk0= Received: by 10.140.169.4 with SMTP id r4mr1987922rve.131.1210314674107; Thu, 08 May 2008 23:31:14 -0700 (PDT) Received: by 10.141.153.8 with HTTP; Thu, 8 May 2008 23:31:14 -0700 (PDT) Message-ID: Date: Fri, 9 May 2008 08:31:14 +0200 From: "=?UTF-8?Q?Tom_Primo=C5=BEi=C4=8D?=" To: "Jon Harrop" Subject: Re: [Caml-list] Re: Why OCaml sucks Cc: caml-list@yquem.inria.fr In-Reply-To: <200805090139.54870.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2979_29480241.1210314674120" References: <200805090139.54870.jon@ffconsultancy.com> X-Spam: no; 0.00; ocaml:01 ocaml:01 citeseer:01 citeseer:01 psu:98 psu:98 metronome:98 metronome:98 threads:01 threads:01 doligez:01 doligez:01 caml-list:01 tail:01 tail:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_2979_29480241.1210314674120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Great post, Jon! 2008/5/9 Jon Harrop : > > I believe these can be fixed by creating a new open source functional > language > for Linux based upon LLVM. However, the lack of a suitable GC is a complete > show stopper. The JVM is the only thing that comes close and it is unable > to > support tail calls without a catastrophic performance cost, i.e. so bad > that > you might as well write an interpreter. > I completely agree with you! I had this idea a long time ago, but I was put off by the enormous code-base one would have to write to make even a simple usable implementation. However, if there was a team gathered that would create, let's say, a "next generation ML" on top of LLVM, count me in. As far as multithreading is concerned, I've gathered some interesting ideas... Primarily, soft threads are a great thing to have, and we would have to look no further than our collegue's Felix language implementation, which supports amaizingly fast green-threads. For the GC, we can turn to our "father", Xavier Leroy, and his paper about the parallel GC for OCaml Light [1]. I'm sure that from the time that paper was written, there has been some improvements and new ideas for GC for multithreading, so by doing enough research and combining the best ideas, we could easily pull it off. A great thing would be to support "pluggable GC", i.e. that the programmer would have the option to select the GC that best sits his program (for example, Metronome-like GC [2] for real-time programs). [1] http://citeseer.ist.psu.edu/doligez93concurrent.html [2] http://citeseer.ist.psu.edu/bacon03metronome.html My $100, Tom ------=_Part_2979_29480241.1210314674120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Great post, Jon!

2008/5/9 Jon Harrop <jon@ffconsultancy.com>:

I believe these can be fixed by creating a new open source functional language
for Linux based upon LLVM. However, the lack of a suitable GC is a complete
show stopper. The JVM is the only thing that comes close and it is unable to
support tail calls without a catastrophic performance cost, i.e. so bad that
you might as well write an interpreter.

I completely agree with you! I had this idea a long time ago, but I was put off by the enormous code-base one would have to write to make even a simple usable implementation. However, if there was a team gathered that would create, let's say, a "next generation ML" on top of LLVM, count me in.
As far as multithreading is concerned, I've gathered some interesting ideas... Primarily, soft threads are a great thing to have, and we would have to look no further than our collegue's Felix language implementation, which supports amaizingly fast green-threads. For the GC, we can turn to our "father", Xavier Leroy, and his paper about the parallel GC for OCaml Light [1]. I'm sure that from the time that paper was written, there has been some improvements and new ideas for GC for multithreading, so by doing enough research and combining the best ideas, we could easily pull it off.
A great thing would be to support "pluggable GC", i.e. that the programmer would have the option to select the GC that best sits his program (for example, Metronome-like GC [2] for real-time programs).

[1] http://citeseer.ist.psu.edu/doligez93concurrent.html
[2] http://citeseer.ist.psu.edu/bacon03metronome.html

My $100, Tom
------=_Part_2979_29480241.1210314674120--