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=AWL 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 8873ABC69 for ; Sun, 2 Dec 2007 17:30:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAN5rUkfUnw6DeGdsb2JhbACCOY0PAQoEBg8a X-IronPort-AV: E=Sophos;i="4.23,240,1194217200"; d="scan'208";a="4817588" Received: from pih-relay04.plus.net ([212.159.14.131]) by mail2-smtp-roc.national.inria.fr with ESMTP; 02 Dec 2007 17:30:21 +0100 Received: from [80.229.56.224] (helo=beast.local) by pih-relay04.plus.net with esmtp (Exim) id 1Iyri1-0006Ar-N3 for caml-list@yquem.inria.fr; Sun, 02 Dec 2007 16:30:21 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] LLVM: A native-code compiler for MiniML in ~100LOC Date: Sun, 2 Dec 2007 16:21:19 +0000 User-Agent: KMail/1.9.5 References: <200711262052.18186.jon@ffconsultancy.com> <47528225.5040802@inria.fr> In-Reply-To: <47528225.5040802@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712021621.19711.jon@ffconsultancy.com> X-Spam: no; 0.00; native-code:01 compiler:01 first-order:01 higher-order:01 runtime:01 trivial:01 higher-order:01 ocaml:01 ocaml:01 run-time:01 overloading:01 vectors:01 matrices:01 native-code:01 ocaml's:01 On Sunday 02 December 2007 10:00, Xavier Leroy wrote: > Your language has first-order, second-class functions, while Mini-ML > has higher-order, first-class functions. A runtime code generator for > Mini-ML would be significantly more complex, since it has to deal with > first-class functions either through closure conversion or > defunctionalization, meaning in both cases dynamic allocation and > garbage collection. Yes, it was a little cheeky of me to call it MiniML. Adding first-class functions turned out to be trivial but making them higher-order will take more work. I would like to build a new language implementation that draws mostly upon OCaml and F#. In particular, I'd like to augment OCaml with run-time types, something akin to type classes, operator overloading, high-performance numerics (built-in types for complex numbers and low-dimensional vectors and matrices, and 32-bit floats as a storage format) and a commerce-friendly intermediate representation. Although I would like to build a platform suitable for commercial applications, I would like the whole thing to be open source and other contributions and ideas are most welcome! There are some important design decisions to make first so I've got a lot of benchmarking to do before I'll start implementing any production-quality code. > Which brings us back to Basile's original question about LLVM and the > Caml garbage collector. The following page suggests that they can > already work together: > > http://llvm.org/docs/GarbageCollection.html To the best of my knowledge there are no working demos of any GCs using LLVM's API for this. Chris Lattner (the lead developer of LLVM) did implement a CLR on top of LLVM but the results are owned by Microsoft. He assures me that it is perfectly feasible and, I believe, Gordon Henriksen already has something working and it is in the pipeline but not yet in SVN LLVM. They were only recently discussing whether or not an external front-end is even theoretically capable of generating OCaml-friendly native-code in order to reuse OCaml's GC. Still, LLVM is an awesome project and, once someone makes the breakthough of a first working tutorial GC on it, I think it will snowball into a great alternative to Mono for creating new languages. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e