From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D232ABDDB for ; Fri, 26 Aug 2005 19:05:36 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7QH5aI9004624 for ; Fri, 26 Aug 2005 19:05:36 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA30870 for ; Fri, 26 Aug 2005 19:05:36 +0200 (MET DST) Received: from [128.93.11.101] (buzet.inria.fr [128.93.11.101]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7QH5TI9004714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2005 19:05:29 +0200 Message-ID: <430F4BD9.5030007@inria.fr> Date: Fri, 26 Aug 2005 19:05:29 +0200 From: Alain Frisch User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lukasz Stafiniak Cc: caml users Subject: Re: [Caml-list] OCamlDuce 3.08.4 References: <430CA5F3.50104@inria.fr> <1124996020.16161.123.camel@localhost.localdomain> <430E13B0.3060906@inria.fr> <1124997485.16161.135.camel@localhost.localdomain> <4a708d20508251700632c6963@mail.gmail.com> In-Reply-To: <4a708d20508251700632c6963@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 430F4BE0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 430F4BD9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; frisch:01 frisch:01 caml-list:01 ocamlduce:01 lukasz:01 ocamlduce:01 type-checker:01 modular:01 type-checker:01 algebra:01 compiler:01 ocaml:01 ocaml:01 cduce:01 cduce:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Lukasz Stafiniak wrote: > What about a notion of supported extensions. These would not be > included into the main distribution, but each of them would have a > branch extending each other, so the user can bake any combination (or > merger) of them. That's interesting, but I don't know how this should work in practice. Each extension might change in a significant way the type-checking and/or code-generation passes. OCamlDuce affects the type-checker in a very limited and modular way (except that two passes of the ML type-checker are run sequentially), but other extensions might really change in deeper ways the type algebra, the structure of the type-checker, or other aspects of the implementation. There are both theoretical issues (interaction of exotic type-checking features) and practical ones (how to design an extensible compiler). For what concerns John's question about the integration of OCamlDuce in OCaml, there are many answers. 1) I'm not directly involved in the development of OCaml. 2) The -Duce part, taken from CDuce, is a big piece of code which still evolves in some experimental ways and which couldn't be easily maintained by someone else in its current state. 3) OCaml is a general purpose language, and the extension adds support for a specific domain (and OCaml is already big enough). 4) One of the design guidelines for OCamlDuce was to obtain an easy merger between two existing implementations; due to this constraint the result is not as elegant or integrated with the rest of the language as one might expect from an ML+CDuce merger written from scratch (but it works). The constraint of being able to compile any existing OCaml program with OCamlDuce, for instance, resulted in the introduction of explicit delimiters {{..}} for all the new constructions, which is syntactically heavy and theoretically useless. 5) It's too early to say whether OCamlDuce is useful or not compared to a simpler solution with two compilers (OCaml, CDuce). -- Alain